[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: remove fedora-usermgmt?



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"?

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

> > > 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.

> 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.

> 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.

> > > 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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]