remove fedora-usermgmt?

[Axel Thimm]

On Thu, Mar 08, 2007 at 08:50:48PM +0100, Michael Schwendt wrote:
> On Thu, 8 Mar 2007 19:48:24 +0100, Axel Thimm wrote:
> 
> > On Thu, Mar 08, 2007 at 07:11:19PM +0100, Michael Schwendt wrote:
> > > On Thu, 8 Mar 2007 19:00:54 +0100, Axel Thimm wrote:
> > > 
> > > > 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".
> > > 
> > > Explain further: why does it go "boom"?
> > > 
> > > Because the packager does not understand that the %uid in the spec file is
> > > a _relative_ value, which is still predictable for the package _user_.
> > 
> > For example. The bug is in different non-determinsitic behaviour this
> > package exhibits dependening on whether and how it is being
> > configured.
> 
> So, in your scenario any package that does "useradd foo" goes "boom"?

No, not my scenario, but any scenario. There are two kind of packages:

a) packages not requiring fixed uid/gids: useradd -r is more than
   enough
b) packages requiring fixed uid/gids: fedora-usermgmt's default of
   going useradd -r breaks the promise of fixed or semi-fixed uids/gids

In neither case does fedora-usermgmt provide any benefit.

So, that's not only about seeking a scenario where it goes boom, it's
about seeking one where it makes sense in the first place.

And yes, iff a package requires a *fixed* uid/gid and used useradd -r
w/o the uid/gid breaks and goes boom just the same.

> [In an earlier mail you complained about fedora-useradd picking a uid
> that useradd would have picked by default, too.]

Yes, so? Do you see a contradiction anywhere? I complain about a tool
that is supposedly used for the *need* of predicting uid/gid that in
reality just calls useradd -r.

> > > > 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 ...
> > > 
> > > If those that would benefit from a fixed uid can get one.
> > 
> > Obviously none needs one otherwise the 99.99% of users would had
> > noticed.
> 
> Users, who want the uids fixed *per site* would notice. Users, who want
> fixed uids per life-time of [backup] data and under consideration of
> complete reinstalls, would notice.

Would, but obviously didn't. Which means that there isn't really any
significant number of users.

> > Alternatively if a package does need one, then obviously none
> > of the 99.99% of users uses this package.
> 
> That might be true. Nobody has said that the package's target group is
> big. It is no silver-bullet. It has negative sides, too. Don't focus
> on fighting everyone who doesn't fight fedora-usermgmt.

No, my focus is on building something that is rock-solid for 99.99%
(and more) of the userbase out there. Not about a dozen users ...

> > So anyway you turn it you will find that this machinery is unused
> > overkill "fixing" something that isn't broken.
> 
> Depends on the definition of "broken". Restrictions and missing
> features can be seen as one form of breakage, too.

The current situation with fixed/non-fixed uid/gid isn't ideal, I
agree 100%, but this kind of fix/workaround just makes things worse by
pretending to fix something that it doesn't fix.

> > > > 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.
> > > 
> > > That is not how fedora-usermgmt works. It is inserted at the
> > > package/repository level, not at run-time when it would be too
> > > late.
> > 
> > What? It does run at package installation time, right? That's far
> > from being repository level. To put the above example in very
> > simple words: Install package A with "usermgmt"-uid 42, then
> > configure usermgmt, then install package B which will have a
> > completely different view of "usermgmt"-uid 42.
> 
> It provides means to avoid that *if* you want that.

OK, I bite. Which means does it provide?
-- 
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/9526c7fa/attachment.sig>