Re: [Lsb-CommonPackaging] Re: rpm specification & alien
On Wed, May 23, 2001 at 10:27:17AM -0500, gk4@us.ibm.com wrote:
> If you have any input, then please respond to lsb-spec@lists.linuxbase.org
>
> Thanks,
>
> George Kraft IV
> gk4@austin.ibm.com
> IBM Linux Technology Center
> FSG's Linux Standard Base
>
>
> ---------------------- Forwarded by George Kraft/Austin/IBM on 05/23/2001
> 10:26 AM ---------------------------
>
> Mark Johnson <mark@duke.edu>@mcgarrett.adsl.duke.edu on 05/23/2001 09:04:01
> AM
>
> Please respond to mrj@debian.org
>
> Sent by: mark@mcgarrett.adsl.duke.edu
>
>
> To: lsb-spec@linuxbase.org
> cc: Chris Yeoh <cyeoh@samba.org>
> Subject: Re: rpm specification & alien
>
>
>
> Chris Yeoh writes:
>
> > Whilst attempting to convert an RPM package to a deb package using
> > alien I noticed that alien appears to have problems with preserving
> > the ownership of files if the user accounts do not (yet) exist on the
> > system on which the conversion is done. ...
>
> > Do we need to add a note to the specification that requires that the
> > RPM packages only rely on the ownership of files being preserved if
> > those files are owned by user accounts required to exist by the LSB
> > spec?
>
> Chris' suggestion sounds both reasonable and sensible. A
> straightforward policy like this would also enable stronger
> enforcement of package file permissions, thereby making it more
> difficult to be sloppy about such things.
>
> Furthermore, a reduced set of allowable permissions might even
> simplify the packaging process.
>
Hmmm, sloppy is already difficult, although confusion probably exists
when dealing with programs like alien and rpm2cpio.
Here's a couple of notes for the specification verbiage mill:
0) rpm itself uses *only* information contained in the package header to
unpack files. That means that the payload's cpio header information is *always*
ignored when installing/upgrading a package. Dunno what alien does,
it should use rpm metadata, not cpio headers, when creating tar payloads
for deb packages.
1) If the rpm header specifies unknown (i.e. to getpwnam(3)/getgrnam(3), that
means that system mis-configuration and/or library incompatibilities can
cause false negatives) user and/or group names for a file, then the
owner/group will be defaulted to 0.0, removing set[ug]id bits from the
file mode as well.
2) There's no intrinsic reason why the cpio header's in an rpm payload
cannot be created with exactly the same information as is in the rpm
header itself, all the necessary information is available when creating the
package. rpm's behavior at the moment is to use the owner/group of the
file as found on the file system for the payload while permitting header
metadata to be specified independently. That means that owner/group
may not be preserved when doing something like
rpm2cpio *.rpm | cpio -dim
But then cpio intentionally mucks with user/group/mode when unpacking
anyways.
73 de Jeff
--
Jeff Johnson ARS N3NPQ
jbj@redhat.com (jbj@jbj.org)
Chapel Hill, NC
Reply to: