Guys,

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.

--
Gerard Beekmans

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

--
http://linuxfromscratch.org/mailman/listinfo/hlfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Reply via email to