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