Date: Wed, 18 Jul 2001 08:47:10 +0300 From: Maxim Sobolev <sobomax@FreeBSD.org> To: Neil Blakey-Milner <nbm@mithrandr.moria.org> Cc: Will Andrews <will@physics.purdue.edu>, Jun Kuriyama <kuriyama@imgsrc.co.jp>, ports@FreeBSD.org Subject: Re: PORTREVISION bumps on dependency changes (Was: Re: cvs commit: ports/print/freetype2 Makefile) Message-ID: <3B5522DE.ECB3BB1E@FreeBSD.org> References: <3B52CDFB.C125416@FreeBSD.org> <7mae253xxw.wl@waterblue.imgsrc.co.jp> <20010716134702.C10331@mithrandr.moria.org> <3B52E709.6514DEC1@FreeBSD.org> <20010716151237.A22423@mithrandr.moria.org> <3B52EF44.FA989ED0@FreeBSD.org> <20010717045537.Z97456@bohr.physics.purdue.edu> <3B541985.8981EE8B@FreeBSD.org> <20010717131449.A24644@mithrandr.moria.org> <3B5439C2.9493996E@FreeBSD.org> <20010717160407.A31908@mithrandr.moria.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Neil Blakey-Milner wrote: > > As I said I see some merits in your position and really do care about upgradebility, but > > proposed approach of handling of shared library version number increase is incomplete at best. > > At worst it is confusing and may lead to a problems if users and creators of upgrade tools > > would rely on it. > > > > The main problem is that we a have large number of ports that inherit LIB_DEPENDS, for example > > most ports that actually link with libpng don't have libpng listed in the LIB_DEPENDS instead > > they inherit it with Gnome, QT, KDE etc., so those packages would not be touched by the > > proposed PORTREVISION bump, while still need a care when there is an libpng.so.X version > > increase. > > I realise it's not perfect at the moment. But that's no reason to > purposefully sabotage the entire process towards upgradeability. There is no sabotage per se, but only reasonable desire to understand rationality behind new requirements, which AFAIK are not documented yet. Nobody loves extra work, and I am not an exception from this rule. > (In your case, the gnome package containing the library that relies on > png will be bumped, and thus the package in question which relies on the > gnome package will be bumped. Theoretically. However, ``make > pretty-print-run-depends-list | cut -d\" -f 2'' will show all your > runtime dependencies, so it's not _that_ hard to trace things that would > change. But it's another thing to remember, I suppose. In the specific > libpng case, which is obviously going to affect lots of people, we can > just grep for the package directly in INDEX.) But this would be a big PITA each time version number of libpng is bumped by its developers, as there roughly 800 (!!!) makefiles that have to be modified. > > There should be another mechanism for this, preferrably automatic. For example we can add an > > arifmetic sum of version numbers of all packages this package depends upon as an another > > component of package version, so it would be automatically bumped as needed (just a raw idea > > off the top of my head). > > Yes, there should be. Unfortunately it's not written yet, and requires > some stuff that's not in place yet. While the change in _any_ version > of _any_ package (or the addition or removal of any) in the dependency > list will always be sufficient, it'll bump a few too many times for most > people's liking. The sort of algorithm that is more likely to work will > separate basic run dependencies from library dependencies (which are > much stronger, but unfortunately isn't possible at package level), and > so forth. > > Basically, we need relative version dependencies (aka ``wildcard > dependencies'') before we can really start thinking about it - runtime > dependencies are only important when the range changes, otherwise it > shouldn't bump a dependency when a new version is available. Library > dependencies are also reasonably fine so long as a major version isn't > changed. That's harder to pick up (but actually rather easy using > ``virtual packages'' aka Provides:, Requires: for names not used for > real packages - 'cgi-webserver' or 'mta' or 'c-compiler' or whatever). > This would be somewhat helped by ``piecemeal packages'', but that's > another story. > > Anyway, we can either decide to regress back to our previous system that > didn't really allow for upgradeability at all, or we can try look to the > future and try do things right whenever reasonably possible. And also > give people who are interested in writing automated upgrading systems a > fighting chance to see what the best way to achieve things are. After thinking about it for a while I found that things could be improved significantly even without major redesign. We can assign each port some non-decreasing number (not sure how to name it, let's call it MAGICKNUMBER for the moment), which to be increased each time when possibly non-backward compatible upgrade is performed. For the first time its meaning could be restricted to shared libraries only, however its purpose could be broader than just that. Then, at the package registration time the appropriate mechanism will calculate sum of MAGICKNUMBERs of all packages this package depends upon and add result into PORTEPOCH (producing PKGEPOCH), thus ensuring that the version number of the package is bumped if necessary. Therefore in our example case of libpng we have to increase number in one place, not in some 800 places. The only problem with this approach could be when dependency list for the package is somehow modified (e.g. some entries removed from its LIB or RUN_DEPENDS), so resulting PKGEPOCH after upgrade is less than before it. However, in this case committer who does the upgrade can compensate for decreased sum of MAGICKNUMBERs by increasing PORTEPOCH, so that resulting PKGEPOCH stays the same. Please let me know what do you think about my idea. -Maxim 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?3B5522DE.ECB3BB1E>