From owner-freebsd-ports Thu Jul 19 0:45: 4 2001 Delivered-To: freebsd-ports@freebsd.org Received: from kalaid.f2f.com.ua (kalaid.f2f.com.ua [62.149.0.33]) by hub.freebsd.org (Postfix) with ESMTP id BF6CC37B401 for ; Thu, 19 Jul 2001 00:44:55 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Received: from Mail-In.Net (borey.f2f.com.ua [62.149.0.24]) by kalaid.f2f.com.ua (8.11.4/8.11.4) with ESMTP id f6J7jIO13193; Thu, 19 Jul 2001 10:45:19 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Received: from vega.vega.com ([212.35.189.220]) by Mail-In.Net (8.11.3/8.H.Z) with ESMTP id f6J7iUI50007; Thu, 19 Jul 2001 10:44:30 +0300 (EEST) Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vega.vega.com (8.11.4/8.11.3) with ESMTP id f6J7hMD73863; Thu, 19 Jul 2001 10:43:22 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Message-ID: <3B568FAC.5844BA4B@FreeBSD.org> Date: Thu, 19 Jul 2001 10:43:40 +0300 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en,uk,ru MIME-Version: 1.0 To: Neil Blakey-Milner , Will Andrews , Jun Kuriyama , ports@FreeBSD.org Subject: Re: PORTREVISION bumps on dependency changes (Was: Re: cvs commit: ports/print/freetype2 Makefile) 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> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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