Date: Thu, 19 Jul 2001 10:43:40 +0300 From: Maxim Sobolev <sobomax@FreeBSD.org> To: Neil Blakey-Milner <nbm@mithrandr.moria.org>, 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: <3B568FAC.5844BA4B@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> <3B5522DE.ECB3BB1E@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Maxim Sobolev wrote: > 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. Any comments? -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?3B568FAC.5844BA4B>