Jaroslaw Polok wrote:
> Hi
>
> Troy Dawson wrote:
>
>> Looks like I missed one
>> SL_inittab_change
>>
>> any others?
>
>
> Troy: We have been discussing packaging yesterday and we came to a
> conclusion that we should use some common naming guidelines, alike:
>
> package-name-VERSION-RELEASE.SITE
>

Sounds like a good, reasonable naming convention.

> (I'll work on CERN stuff to be renamed this way)
>
> I think If you are already rebuilding all these you could rename them
> too:
>
> SL_desktop_tweeks-1.1-1 -> desktop_tweeks-1.1-1.SL
> etc .. just an idea ..
>

On the one hand that seems nice, but I think it would cause more pain to do
this.  Not more pain for me, but more pain for the users and administrators.

Right now when an admin needs to get a certain tweek, they know that all they
have to do is look for the zz's and see if we have something already set up
for them.  If it's not there, then they know they have to either do it
themselves, or ask us to see how hard it will be to do the tweek.  I don't
mind changing the zz to SL, but the concept is the same.

There also are going to be rpm's that are full blown packages added by the
Scientific Linux community, or RedHat rpm's that we have modified in some way.
  These are going to have that RELEASE.SITE in their name.  So a user/admin is
going to have a problem figuring out which are the real packages and which are
the tweeks.

I would prefer to keep something at the beginning of the main name.  Either
zz_, SL_, tweek_, I don't care too much, but I'd like to keep it there.  If
everyone disagree's with me, I'll change it, but that's my opinion.

> As for the list below:
>
>>> SL_sendmail_accept-1.0-2.src.rpm
>
>
> -> this one is not installed by default , is it ?
> (we at CERN do not allow individual machines to accept
> SMTP by default ... I'm sure that there are other sites
> doing this)
>
I believe Connie already answered this.  No, this definatly isn't installed by
default.  This is just there for a convienience.  For those that need/want it,
it makes it easy for them to change sendmail, without messing everything up.

>>
>>
>> SL_inittab_change-1.0-4.src.rpm
>
>
> I'm not sure what is this one doing ?
>

On a generic RedHat, if you startup the machine in single user mode, you are
automatically logged in as root, with no password or anything.  This makes it
so that you have to log in with a password in single user mode.

>
>>> Are there any more rpm's that do these little tweeks that I should put
>>> in?
>>> (I'm meaning generic tweeks, not site specific tweeks)
>
>
> We have a modified redhat-config-securitylevel
> which adds an option for AFS client (basically
> opening afs3-callback port for incoming):
>
> Would that one be of generic interest ?
>

Sortof, but not really.
It really isn't a tweek, it's a change in the main rpm.  So everyone using
Scientific Linux either has to use your new redhat-config-securitylevel or
not.  If there was some way to make it so we could use the generic RedHat
redhat-config-securitylevel and then adding this one rpm, it would have the
right openings for AFS, then it would definatly be a yes.

> - I think that openafs itself is also interesting
> for lot of sites: I *think* that compiling krb5 in
> (which you do as I understand) does not disturb people
> who use krb4 only (or mixed) setups  (we always have disabled
> krb5 for oa builds) ?
>

I think openafs is worthy of a discussion in itself.  I like how you all have
done the kernel modules.  I really want to get it so that it works for both
CERN and Fermi and everyone else who uses AFS without any modifications other
than the 'ThisCell'.

> I will repackage our apt,apt-cern and synaptic (slightly newer version
> than in SL) to have:
>
> apt packages - not including any site-specific info
> apt-autoupdate - scripts for using apt from cronjob (service
> apt-autoupdate disabled by default)
> apt-config-X.Y.SITE packages (or apt-config-site-X.Y if anybody wants
> to have more than one site config for apt)
>
> Also probably additional perl modules we provide are useful
> for others (but these shall rather go into contrib area
> I believe ?)
>
> Jarek

Yes, they might go into contrib, but they would definatly be a good addition.

Troy

--
__________________________________________________
Troy Dawson  [log in to unmask]  (630)840-6468
Fermilab  ComputingDivision/CSS  CSI Group
__________________________________________________