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
Attachment:
pgp6RW0aidGZ8.pgp
Description: PGP signature