Re: Best method of changing permisions...

[Jeff Johnson <jbj redhat com>]

On Thu, Aug 15, 2002 at 12:33:02PM -0400, James Olin Oden wrote:
> Hi All,
> 
> I would like to create a package that would be used to change the
> permsions of various files on a system.  Its easy enough to do
> this via chmod in a post or pre scriptlet, and make the thing 
> dependent on any rpms that contain the files it would change to
> insure proper order of install, but by using the chmod command I
> have basicly lost the ability to verify these files via the rpm
> command.
> 

Yup. This is a variant of file management vs. package management,
where rpm is a package manager, and most humans are file managers.

> I did think of possibly repackaging the files whose 
> permissions we wish to change.  That seems kind of ugly 
> for two reasons:
> 
> 	- I would probably end up repackaging a lot of files.
> 	  Think really big package of stuff already on the system.

With --repackage? Please don't, repackaged packages are deliberately
damaged (by addition of a RPMTAG_REMOVETID) in order to prevent
exactly this behavior. 'Tain't too hard to prepare a package
from a tarball, do that instead.

> 	- I am not sure how RPM handles files owned by two 
> 	  packages.
> 
> So is there a way to update the RPM database such that the changed
> permissions would be seen as the right permissions?  Should
> there be a way of doing this?
> 

No way to change the database except by installing another package.
That's package management. And, since new-fangled signatures on
header immutable regions which contain MD5 sums of files used
to verify the installed base is wired into the trust model of
rpm, well, there ain't no easy way to permit the database data
to be changed.

What does exist in rpm ATM:

1) a concept of "shared" (i.e. same MD5 sum) files, most useful
with sub-packages that can be installed together/separately, where
one or the other or both package(s) share (and co-own) exactly
the same file.

2) last installed package changes the file installed state
of a file shared with earlier installs from NORMAL -> REPLACED.
That should also disable --verify, but I haven't checked for awhile.

Still, whacking in new permissions with a %post and living
with the false positive ain't *THAT* bad, is no worse in effect
than having, say, some oddball umask during install.

(aside: --rollback in rpm-4.1-0.81 is now at least as good as what's in
rpm-4.0.4).

73 de Jeff

-- 
Jeff Johnson	ARS N3NPQ
jbj@redhat.com (jbj@jbj.org)
Chapel Hill, NC