Date: Tue, 17 Jul 2001 16:04:08 +0200 From: Neil Blakey-Milner <nbm@mithrandr.moria.org> To: Maxim Sobolev <sobomax@FreeBSD.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: <20010717160407.A31908@mithrandr.moria.org> In-Reply-To: <3B5439C2.9493996E@FreeBSD.org>; from sobomax@FreeBSD.org on Tue, Jul 17, 2001 at 04:12:34PM %2B0300 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue 2001-07-17 (16:12), Maxim Sobolev wrote: > Neil Blakey-Milner wrote: > > > On Tue 2001-07-17 (13:55), Maxim Sobolev wrote: > > > > On Mon, Jul 16, 2001 at 04:42:36PM +0300, Maxim Sobolev (sobomax@FreeBSD.ORG) wrote: > > > > > The FreeBSD package contains exact version of all packages it depends upon > > > > > (@pkgdep), isn't it? So, if one of those packages (library) has been upgraded > > > > > then the new package linked against this new library will contain correct > > > > > information about which versions of package with library it requires and if > > > > > upgrade is performed properly this should prevent from using packages linked > > > > > with oldest library with newest one and vice versa. I do not see what > > > > > PORTREVISION bump would add into this. > > > > > > > > How about "I am a package that has been linked with that newer > > > > version of the other package with the library bump etc" instead > > > > of "I am possibly a copy of the package with the same version > > > > number that has been linked with that newer version ..." ? > > > > > > Yes, it has some merits, but still how about the following events (in chronological > > > order): > > > 1. User installs package foo-1.0 which requres shared library from another package > > > bar-1.0; > > > 2. For some reason package foo-1.0 has been modified and its PKGREVISION number has been > > > increased to 1; > > > 3. Package bar-1.0 has been updated to new version 2.0 and version number of shared > > > library from this package had been bumped. To indicate that PKGREVISION of port foo-1.0 > > > has been increased to 2, as you suggest; > > > 4. For some reason package building cluster fails to build new package foo-1.0_2 (for > > > example due to some incompatible API changes in the shared library from the new bar-2.0 > > > package); > > > 5. The user checks for updates for his packages and sees foo-1.0_1 and bar-2.0. > > > According to your logic, he concludes that that package foo-1.0_1 is the package that > > > linked against bar-2.0, but this is WRONG, in fact he just missed previous update of the > > > foo package. > > > > > > Therefore, as you can see, PORTREVISION bump is in fact rather weak indicator of "I am a > > > package that has been linked with that newer version of the other package with the > > > library bump etc". > > > > I don't really have the energy or time to argue about this - if you > > decide you don't care about upgradeability, feel free to not act on > > ideas gleaned from package systems far superior to our own (and, in > > particular, Debian's). > > > > In any case, this is specifically for upgrade tools (as yet unwritten, > > but really easy to write if people actually obey the guidelines for > > revision bumping) that will solve dependency problems automatically, and > > support undos. Again, only possible really if the package contents > > don't change (non-trivially) without the revision changing. > > 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. (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.) > 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. 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?20010717160407.A31908>