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 __________________________________________________