On Wed, 17 Mar 2004, Michael Jennings wrote: > On Wednesday, 17 March 2004, at 07:17:15 (-0800), > Michael A. Peters wrote: > > > So while there really is no way to stop rpm from changing > > permissions on a file that rpm owns when upgrading, there are > > facilities to stop it from re-adding a service to chkconfig that has > > been removed from chkconfig management. > > > > I'm not fond of situations where an administrator is forced to use a > > bolton to sysV because of the way that the distro writes the spec > > files. > > First off, and let's be very clear about this, RPM must take ownership > of certain files and file meta-data in order to be effective as a > package manager. Permissions and file ownerships are most definitely > in that category. Otherwise, you wouldn't get very far after > installing /bin/sh with mode 000. > While I agree with you, it is possible for a package management system to allow the admin to tell it where specific things have been overridden. Probably, the reason this has never been implemented is it would be very difficult to get fully right. For instance if the admin did something like (note this command doesn't exist): pkgAdmin --setperms=0400 /etc/supersecretfile Then, with RPM for instance you would not want to modify the actual header in the database (or you mess up its digest, and signature, and...) so rpm would have to have a data file of package overides. If that much was handled, then what happens with things like verify? Intuitively, the admin would want the default verify to take his/her changes into account (the ones communicated to the package management system), but in some cases he/she may want to verify from only the stand point of the headers delivered via the packages. However you slice it things get more complex to do something like a verify. Another complexity would be how would you roll such administrative changes into rpm's rollback functionality. As it is the repackaged packages get the files as they are on the filesystem, but the adminstrative overrides would be outside of a package, so you would have to track them as transactions, also, if you wanted to roll them back (yes, we are straying from KISS). Not mention, you would open the door for wackiness like packages that use this facility to overide other packages (its not really a leap when you think of all the admin's that uses rpms to configure there systems). The bottom line, though it could be done, it would need to be thought through a thousand times, and even then some borkage is bound to occur. So who is going to provide the patch to implement this (-; > Secondly, binary RPM's are intended to comply with the properties of > the distribution. If you're mucking around with files owned by your > distribution, you need to do it the right way. Take the SRPM and > modify it to suit your needs, build it, and install the resulting > packages with the permissions you desire. > > Whatever packaging system you use, be it RPM, dpkg, HP's sw depot, > Solaris pkg, or whatever, it has to maintain a certain level of > control, consistency, and sanity. If you find yourself continually > being bitch-slapped by your package manager, perhaps there's a better > way of doing what you're trying to do. > Could not agree more. Nice wording too (-; Cheers...james > Michael > > _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
