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.