Date: Fri, 4 Jan 2013 11:23:45 +0000 From: "b.f." <bf1783@googlemail.com> To: Lev Serebryakov <lev@FreeBSD.org>, freebsd-ports@FreeBSD.org Subject: Re: Shared library version bump policy & suggestion to track these bumps formally Message-ID: <CAGFTUwOW%2BO_e5oB0opJpEGdAgcO7dGn114Bn9wR5RKEFH-xU5w@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Lev wrote:
>
> Now, when some port after update installs new version of shared
> library, used by other ports, here are two variants:
>
> (a) To bump versions of all dependant ports (PORTREVISION=${PORTREVISION} + 1)
>
> (b) Don't touch other ports, but add copy'n'pasted item into
> UPDATING with instructions for users of portmaster, portupgrade
> and binary pkg-ng packages.
>
> Question is: which way is better? Why sometimes first way is selected
> and sometimes second one? Is here any policy to select between them
> in different cases?
You're always supposed to do (a), for those default packages that must
be rebuilt because of the change -- whether because of a shared
library version change, or something else.
(b) is only as a reminder for those users that have non-default
packages that may need to be rebuilt, or as a stopgap in an emergency
-- it is not supposed to replace (a). It is usually used when someone
failed to notice that a large number of ports link to a shared
library, but that shared library is not in the LIB_DEPENDS of those
ports, because it is in the LIB_DEPENDS of a port that those port
depends upon (if you want to reopen the debate about whether this
non-redundant dependency accounting is the right thing to do, that may
be worthwhile), and needs to alert users while the problematic ports
are being fixed. It is often a sign that an exp-run should have been
requested, but wasn't.
>
> Personally, I don't like both ways.
>
> First one is error-prone for maintainer: dependency could be
> optional and turned off by default, for example.
Then a PORTREVISION bump isn't necessary, but an UPDATING note may be advisable.
>
> Second one is error-prone for users. And, to be honest, I don't
> like when formal task is performed by hands. All these records in
> UPDATING is copy'n'pasted with replacement of port name, receipt of
> upgrading is always the same (yes, I know, that there are more
> difficult scenarios in UPDATING too, I don't speak about them now).
> Why this receipt should be performed by user, not by tool!?
>
There are some ways to refine the updating process -- like, for
example, lstewart@'s:
https://lauren.room52.net/hg/scripts/raw-file/tip/libdepend/libdepend.sh
There is certainly room for improvement in the standard tools here.
But some ports may need to be rebuilt for reasons other than shared
library changes, which may be difficult to detect automatically in
every case.
> I suggest to have new variable in port's Makefile: BORDER_VERSIONS
> or something like this. Let it will be list of port's versions, when
> shared libs are updated and all dependent ports should be rebuild
> too.
>
> Then, portmaster/portupgrade could add "forced updates" to queue
> automatically (like with "portmaster -r <port>" / "portupgrade -fr
> <port>") if port cross (inclusive) one of versions from this list.
>
> Something like this:
>
> BORDER_VERSIONS=0.48 0.65 1.0_1
>
> And if port is updated to version 0.48 or higher from
> version STRICTLY LESS than 0.48 (and same for 0.65 and 1.0_1), all
> ports, which uses this library, will be rebuild too.
This has some advantages, but how would it be used efficiently by the
package-building clusters, in the absence of PORTREVISION bumps? And
for end users, is BORDER_VERSIONS better, in most cases, than
improving the package-updating tools to perform automatic checks
during partial updates, as in lstewart@'s script? -- how would
BORDER_VERSIONS overcome the existing problems in dependency
accounting that I mentioned above, without forcing unnecessary
rebuilds?
b.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGFTUwOW%2BO_e5oB0opJpEGdAgcO7dGn114Bn9wR5RKEFH-xU5w>