Date: Tue, 12 Mar 2002 10:20:31 +0200 From: Neil Blakey-Milner <nbm@mithrandr.moria.org> To: Maxim Sobolev <sobomax@FreeBSD.org> Cc: Akinori MUSHA <knu@iDaemons.org>, MANTANI Nobutaka <nobutaka@nobutaka.com>, ports@FreeBSD.org Subject: ABIVERSION... Message-ID: <20020312082030.GA18590@mithrandr.moria.org> In-Reply-To: <1015886047.1763.26.camel@notebook> References: <200203111725.g2BHPVF52248@freefall.freebsd.org> <86adte28qw.wl@excalibur.nobutaka.com> <3C8D0B5D.3186A73D@FreeBSD.org> <86r8mqajfe.wl@archon.local.idaemons.org> <1015886047.1763.26.camel@notebook>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue 2002-03-12 (00:34), Maxim Sobolev wrote: > On Mon, 2002-03-11 at 23:22, Akinori MUSHA wrote: > > At Mon, 11 Mar 2002 21:54:05 +0200, > > sobomax wrote: > > > > > Chase increase of freetype2 shlib version. > > > > > > > > Don't you bump PORTREVISION? > > > > > > No, I didn't due to the reasons already discussed here several times. > > > In short, this would require from me to bump PORTREVISION in some > > > 2,600 ports (`cd /usr/ports ; make search key=freetype2 | grep ^Path | > > > wc -l') and I am not paranoidal enough. > > > > I can understand your sentiment here that it is too paranoiac and > > unrealistic to touch 2,600 Makefile's, but I believe you should at > > least bump the PORTREVISIONs of the ports that directly lib-depend on > > libfreetype2. That's the way we've done things since we introduced > > PORTREVISION. > > > > Most of us still remember what happened when libpng's major was bumped > > without bumping the dependent ports' PORTREVISIONs. Innocent users > > who used `pkg_version -c' scripts to upgrade packages all got stuck > > and forced to reinstall almost everything by hand. > > > > Now I can say it is likely that the total cost would have been lower > > if we had bumped the PORTREVISIONs of (literally) thousands of ports > > that depended on libpng. > > > > I'm sure you are not going to repeat the mistake.. > > As I said earlier, what we really need is the feature that will track > ABI-incompatible upgrades and when such upgrade is performed bump > PORTREVISION of all dependent ports automagically. Actually I've already > described prototype of such feature and instead of spending out time > arguing whether or not we need to bump PORTREVISION on 10 out of tens or > even hundreds ports that use freetype (waste of time IMO) in the long > run we are better off to implement such feature and forget about it. > > In a nutshell idea is to assign each port with something called > PKGABIVERSION (>=0, non-decreasing), which will need to be increased > each time when some ABI-incompatible change is committed (e.g. shlib > version bump) and make PKGREVISION of each port be an arithmetical sum > of PKGABIVERSION's of all its dependencies and its own PORTREVISION. > Actual implementation I'm leaving as an exercise for the reader, because > I do not use portupgrade by myself and therefore have no interest in > doing it on my own. For me `pkg_delete -r freetype2\* ; cd > /usr/ports/x11/gnome ; make reinstall' is absolutely sufficient. When listening to your comments on this previously, I never quite grasped that you were talking about a PKGABIVERSION version that somehow filtered through to ports that depend on it. This I can see working. There is the question of implementation, and that all depends on what we want out of this. We can create a tool that will tell the committer which ports need their PORTREVISION bumped when they check in an upgrade, and maybe even auto-providing a suggested patch to apply. Or, as you mentioned, make PORTREVISION:=PORTREVISION+DEPABIVERSION, and auto-provide a patch to bump DEPABIVERSION. Or we just wait for the port build stage to compare, for every port build that occurs. So either one person or system does the work, or it's every system doing the work. I don't believe we can use an arithmetic sum. We could use a _change_ in the arithmetic sum (ie, because we might remove a dependency, it might go down) but that would mask where the increase in ABI version on a dependency is equal to the removal of the dependency with an equivalent ABI version. I'd prefer auto-generating the patch, but I'm happy if we go with the change in arithmetic sum and have manual intervention for special cases. Maybe we can go for the change in the md5 of the names of the packages (without versions) we depend on and their ABI version? If we don't go for a patch for a committer to apply (or maybe eventually automating it) , we have to make sure all the relevant metadata is available to pkg_version, portupgrade, and the ports build when the full ports tree isn't available. One possibility is to store it in ports-base somewhere centrally for all ports, so that it's available for builds that aren't done in full ports trees. Or we can just assume people have a full ports tree. But that's not something one person can decide. My personal choice: Change in md5 in the names of the dependencies and their respective PKGABIVERSION variables, providing a patch to the committer to apply (we may need to use some non-ports tools such as a database of port variable values to generate it). This patch increments the current value of PORTREVISION. (This approach assumes each port maintains its own PORTREVISION, and doesn't gain it from a master port.) This centralises the administration in the ports tree, in a similar way to Debian's approach. If I can get buy-in that this is the way to go, I'll be willing to implement it. But because of the history of my ports work, I'm not willing to work on it if it's going to get ignored again. I'm not looking for "It will be committed if you implement it", but "yes, we see there's a problem, and your solution seems practical, please go off and do it". The above applies to virtual package support too. Neil -- Neil Blakey-Milner nbm@mithrandr.moria.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020312082030.GA18590>