freebsd stable - Dec 2014 - I do not quite understand why a BIND upgrade needs to touch soo much.

On Mon, Dec 15, 2014 at 5:10 PM, Willem Jan Withagen <wjw at digiware.nl>
wrote:
>
> Yup, more than true in the ultimate case.
> Although 'portupgrade bind99' in this case did not require any
other
> packages to be upgraded too.
>
Hm; I'd expect it to notice the new gettext and build that as well, since
the new bind might depend on changes in it (it has no way of knowing that
in this case it's safe). OTOH this explains some of the screw cases that
portuprade used to get me into, which are why I use portmaster these
days....

Still leaves the point that 'pkg upgrade bind99' removes
packages
> without reinstalling those. The only alternatives are:
>  -      pkg upgrade, and everything is upgraded
>  -      capture the list of deletion, and manually re-add them after
>         the upgrade
>
This comes of prebuilt packages. In theory, a poudriere setup could be
managed so that you updated only the bind99 Makefile. If you're relying on
the standard packages, or updating a poudriere ports tree without checking
/usr/ports/UPDATING first, you have no way to limit the update and get a
bind99 package built against the old gettext; you have little choice but to
upgrade everything.

Any other package manager would give you the same result. (Something like
nix gives you the option of the "In theory..." above about poudriere.
The
*default* behavior won't differ.)

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at
sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

In article
<CAKFCL4UAzSXKoB+Jo=a=nv+WaejcEXoDh2-yMauZxf_Dd8J4Eg at mail.gmail.com>,
allbery.b at gmail.com writes:
>On Mon, Dec 15, 2014 at 5:10 PM, Willem Jan Withagen <wjw at
digiware.nl>
>wrote:
>>
>> Yup, more than true in the ultimate case.
>> Although 'portupgrade bind99' in this case did not require any
other
>> packages to be upgraded too.
>>
>
>Hm; I'd expect it to notice the new gettext and build that as well,
since
>the new bind might depend on changes in it (it has no way of knowing that
>in this case it's safe).
No, portupgrade has no concern over whether there's a new gettext
unless you tell it to upgrade dependencies recursively -- it doesn't
look at the gettext port at all otherwise.  The dependencies in ports
are on the files that are installed (usually shared libraries or
pkgconf data files): if the required files already exist, the ports
framework doesn't look at the dependency.  (If the required files
hadn't already existed, then in this case they'd probably fall afoul
of CONFLICTS checking when attempting to install the dependency and
the portupgrade would fail.)  Most of the time this would work, but it
would fail in interesting ways and leave you unsure as to whether your
set of installed packages was actually self-consistent.
>This comes of prebuilt packages. In theory, a poudriere setup could be
>managed so that you updated only the bind99 Makefile. If you're relying
on
>the standard packages, or updating a poudriere ports tree without checking
>/usr/ports/UPDATING first, you have no way to limit the update and get a
>bind99 package built against the old gettext; you have little choice but to
>upgrade everything.
It's a trade-off, of course.  Some other operating systems have armies
of volunteers to manage old versions of packages, backporting security
fixes and whatnot; in FreeBSD we have at best a brigade, not an army,
and have historically chosen to always build self-consistent package
sets and only support the versions supported the the upstream
developers.  This is sadly why a number of ISVs have gone on a
"self-contained packaging" trip, so if you install commercial
software, you may no longer know how many unpatched copies of the JRE
(for example) (or Python or FreeType) you have sitting around buried
in some application's directory tree.

That said, I do think there's a bug in pkg 1.4's dependency solver.  I
upgraded my home workstation over the weekend, and it wanted to
uninstall a number of packages[1] that did not have any plausible
connection to the things that changed.  After allowing the upgrade to
complete, I reinstalled the uninstalled packages with no issues.

-GAWollman

[1] inkscape was one; I don't recall the others.

On 15-12-2014 23:26, Brandon Allbery wrote:
> On Mon, Dec 15, 2014 at 5:10 PM, Willem Jan Withagen <wjw at
digiware.nl>
> Hm; I'd expect it to notice the new gettext and build that as well,
since
> the new bind might depend on changes in it (it has no way of knowing that
> in this case it's safe). OTOH this explains some of the screw cases
that
> portuprade used to get me into, which are why I use portmaster these
> days....
augh, that is something to check. I've been using portinstall/upgrade
for a serious time. Did have some awkward moments, but always consider
them pilot-error...
> Still leaves the point that 'pkg upgrade bind99' removes packages
>> without reinstalling those. The only alternatives are:
>>  -      pkg upgrade, and everything is upgraded
>>  -      capture the list of deletion, and manually re-add them after
>>         the upgrade
>>
> 
> This comes of prebuilt packages. In theory, a poudriere setup could be
> managed so that you updated only the bind99 Makefile. If you're relying
on
> the standard packages, or updating a poudriere ports tree without checking
> /usr/ports/UPDATING first, you have no way to limit the update and get a
> bind99 package built against the old gettext; you have little choice but to
> upgrade everything.
This calls for something in /etc/crontab like:
 ( diff -N /usr/src/UPDATING ~/tmp/UPDATING || cp /usr/src/UPDATING
~/tmp/UPDATING )
What I us to get alerted when /usr/src/UPDATING gets changed.

But then still I'm afraid that just getting a poudriere package set for
just only bind99 is perhaps a bit too much.
> nix gives you the option of the "In theory..." above about
poudriere. The
> *default* behavior won't differ.)
> 
--WjW