User IDs and Group IDs
gerard at linuxfromscratch.org
Tue Nov 22 10:34:45 PST 2005
There seems to be some issues relating UIDs and GIDs especially between
BLFS and CLFS.
I'm not going to point the finger whose fault this is and I don't care
about personal issues as I have noticed things don't get done because
people don't care for other people for whatever reason.
There is a technical problem here that will remain here long after
people with or without grudges have left LFS and we'll be left to pick
up the pieces.
If there are any personal issues, check them at the door. This
"technical" has to be addressed and fixed, one way or another.
The problem as I see it is different projects use the same UID or GID
number for a different purpose. There will be people who have to take
instructions from both CLFS and BLFS, and possible other projects down
the road. I'm not sure to what extent HLFS is effected, but there is a
possibility of it happening sooner or later.
All our sub-projects can't run amock and do their own thing, not support
other projects. In the end it's the users who suffer from this and there
is no reason for this to happen. During development personal issues are
to be put aside for the sake of getting the *LFS work done.
To address this UID and GID issue, a possible solution seems pretty
straight-forward: we'll maintain a UID and GID list that every LFS
project refers to if they need to use a service or ID or whatever. And
if they introduce a new one, add it to the list so *everybody* knows
about it, and not end up using an existing ID.
Since there is already some conflict, changes need to be made. It seems
fair that the project who caused a duplicate in IDs (ie., whomever last
started using an ID that was already taken by another project) will have
to relinquish that ID and start using a different one.
This discussion should continue here on the lfs-dev list since it
effects all our projects in one way or another.
Are any of the project leads (blfs, clfs, hlfs) opposed to maintaining a
shared file like this, and possible more such files down the road if
they become needed? I'll speak on behalf of the LFS project itself and
say that I don't see a problem here. In fact, I think it's something
that will benefit us.
Replies to lfs-dev please.
/* If Linux doesn't have the solution, you have the wrong problem */
More information about the blfs-dev