User IDs and Group IDs

Gerard Beekmans gerard at
Tue Nov 22 10:34:45 PST 2005


There seems to be some issues relating UIDs and GIDs especially between 

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.

Gerard Beekmans

/* If Linux doesn't have the solution, you have the wrong problem */

More information about the cross-lfs mailing list