[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#134658: ITP: lsb -- Linux Standard Base 1.1 core support package



On Feb 19, Thorsten Kukuk wrote:
> On Tue, Feb 19, Martijn van Oosterhout wrote:
> 
> > On Tue, Feb 19, 2002 at 12:09:51AM -0500, Andrew Pimlott wrote:
> > > On Mon, Feb 18, 2002 at 08:42:38PM -0600, Chris Lawrence wrote:
> > > I would lobby to change the spec not to mention bin, daemon, or any
> > > of the optional users/groups, at all.  They are not specified in a
> > > useful way, so they're at best dead-weight, and at worst an
> > > opportunity for conflicting interpretations.
> > 
> > IIRC, I think the reasoning went as follows:
> > - The LSB format is based on RPM which has a CPIO archive
> > - CPIO archives store uid/gids as numbers, not names
> > - Installed programs may want to use the daemon user
> > - Hence the daemon user must have a fixed uid
> 
> Have you ever looked at RPM? I don't know which cpio format the RPM
> internal cpio is using, but the above is wrong, the demon user must
> not have a fixed uid. RPM does not depend on fixed uids.

Heh... this discussion was on lsb-discuss, what, 6 months ago.

As far as I can figure out, there is no technical reason to require
uid and gid 1 to be bin, and it's bad programming practice to assume
any uid corresponds to any named user.  When this last came up, I
don't think anyone came up with a good reason not to drop the
specification; indeed, I assumed it was gone until I went back and
reread the section closely.

Let's put it this way: making uid/gid 1 a requirement means Debian
probably will never conform to the spec, because of the problem of
breaking existing installs.  It also creates problems for people who
want to use NIS across multiple systems, as Solaris uses uid/gid 2 for
bin (like Debian), or running LSB apps on Solaris/x86, which could be
conformant if Sun or a third party wanted to do the work.


Chris
-- 
Chris Lawrence <lawrencc@debian.org> - http://www.lordsutch.com/chris/



Reply to: