At Thu, 28 May 2009 21:33:13 +0200, Ingolf Steinbach
<ingolf.steinbach%googlemail.com@localhost> 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
is....
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
scheme.
--
Greg A. Woods
Planix, Inc.
<woods%planix.com@localhost> +1 416 218-0099 http://www.planix.com/
Attachment:
pgpfW50gwozeM.pgp
Description: PGP signature