remove fedora-usermgmt?

[Axel Thimm]

On Thu, Mar 08, 2007 at 06:47:41PM +0100, Michael Schwendt wrote:
> On Thu, 8 Mar 2007 18:10:00 +0100, Axel Thimm wrote:
> 
> > It's not about a beauty contest, it's about whether this is something
> > we want to see being tuned like that at all.
> 
> So far there is no alternative. Perhaps we could use the core+extras
> merge to start a global fedora uid/gid registry finally?
> 
> > I wonder how many of the
> > packagers making use of fedora-usermgmt are really aware that they are
> > not really creating predictable uids/gids?
> 
> If not 100%, then the review process has failed. The packagers have
> registered their uid/gid (from 1 to 34 so far, imagine that!) at
> http://fedoraproject.org/wiki/PackageUserRegistry and apparently have
> never examined/verified their packages.
> 
> > And how many of them do
> > rely on this feature and are falsely deceived?
> 
> Without running into any symptoms? As in requesting uid 25, but
> getting 325 and not noticing it? ;)
>  
> > If your package works with plain useradd -r, that's OK, the use
> > that. If not, then fedora-usermgmt does *not* save your day. Even
> > worse: It may look localy as if it does and when deployed to users
> > your package will boom.
> 
> I agree with the first part, although it does not even try to achieve
> what fedora-usermgmt attempts at. But default fedora-useradd is
> just like plain useradd, so no "boom".

Read closer: The above was splitting the use cases into such that
would work with plain useradd -r and such that really require
something more. You agree with the first set of packages, so let's
focus on the latter:

The packager has setup his fedora-usermgmt and indeed the uid/gid he
requests in his local setup is predictable and works fine for him. But
not on 99.99% of the users' system. There it goes "boom".

And if there is no such package requiring more than useradd -r, then
that's for the best, we can simply rip it off all 34 packages that use
fedora-usermgmt ...

And the next worse illusion with thsi concept: The fixed uid approach
makes mostly sense for uids that are spawning packages like say
uid/gid apache. So if we assume we have need for such a uid/gid and
one package gets installed before configuring and the other after then
you get de-synced uid/gids on the *same* system.

The more I think about this solution the more of a can of worms it is.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20070308/05da7fd6/attachment.sig>