tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: handling of new user/group additions in binary packages is broken

At Thu, 28 May 2009 21:33:13 +0200, Ingolf Steinbach 
<> wrote:
Subject: Re: handling of new user/group additions in binary packages is broken
> Does that mean that pkg/41100 should be re-opened for incorporating
> the fix in the base system? If so, would you kindly append this
> information to the PR?

Yes, I believe the initial description and instructions for reproducing
the problem in pkg/41100 are exactly the same problem I describe.
(it's a wonderful co-incidence that your PR used as an example the same
package which brought the issue to a head for me! :-))

I'm not sure what the best solution for the NetBSD project as a whole

As released NetBSD-5 appears to have the bug, but for a different
reason.  All previous releases have the bug too of course (NetBSD-4 is
still shipping pkg_install-20061103 by default!!!).

If pkgsrc-2009Q1 were made to include and require pkg_install-20090528
or newer[*] then users of binary packages built from the pkgsrc-2009Q1
branch should be OK.

I think in an ideal world pkg_install-20090528 would also be pulled up
onto to the pkgsrc-2008Q4 branch as well (assuming that it will be
supported until at least the 2009Q2 branch is cut).

Note these solutions also require that bootstrapping of a new
pkg_install be made to work well from binary packages -- it won't yet
though because there's no easy mechanism for such global dependencies in
binary packages, unless every package is made to require a new
pkg_install.  Even then there will still be room for problems if the
user tries to install too much with the first pkg_add command.  pkg_chk
could do it, for those of use who use it as a front-end to pkg_add....

(I will note that the infamous +REQUIRE script could have been used for
exactly this kind of purpose -- I should campaign again for its
resurrection!  There was so much foresight in the design of pkg_install
-- and yet so much has been lost in the way we use it now.)

Of course these solutions only solve the problem for those who are
starting from a situation where they have an existing machine with some
local users and/or groups and they are installing new packages, and they
manage to retrieve a fresh build of all the binary packages done after
this pull-up has occurred.

There may be other issues with pkg_install-20090528 too, though my vague
understanding is that it is considered by at least some pkgsrc
maintainers to be highly desirable to pull the latest pkg_install into
netbsd-5 (and of course this would mean it must be pulled up onto the
netbsd-4 branch too!  all supported releases must have all relevant
pull-ups done!)

In the end the problem will work itself out for the netbsd-6 release,
and possibly even any patch releases on netbsd-5 (iff pull-ups are done)

It does only affect those who try to do package upgrades, or add new
packages, using binary packages on production machines with locally
created users and/or groups, and who don't remember to upgrade
pkg_install first (assuming they are in fact working with the latest
pkgsrc-2009Q2 after a pull-up of install-20090528 has been done so that
upgrading pkg_install will actually fix the problem).

I don't know how many other folks have know about this problem (I've
known about it since pretty much the very beginning, though I always did
things to avoid it instead of trying to fix it properly), but the
general disbelief shown in reactions to our reports suggests few if any
others.  I guess that's a good testament to just how many users always
build from source every time and on every system!

[*] note that pkgsrc (even pkgsrc-current, but also 2009Q1) does not yet
    require the new pkg_install-20090528 -- it's still stuck back at
    20070813 for reasons that I don't really understand.  pkgsrc-2009Q1
    still only has pkg_install-20090326 too -- much has changed since
    the branch was cut.  I suppose only the critical 20090528 change,
    really needs to be pulled up, along with any other proper fixes, but
    that isn't easily supported in the pkg_install version numbering

                                                Greg A. Woods
                                                Planix, Inc.

<>       +1 416 218-0099

Attachment: pgpfW50gwozeM.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index