Date: Tue, 17 Jul 2001 16:12:34 +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: <3B5439C2.9493996E@FreeBSD.org> References: <200107121008.f6CA8iN37556@freefall.freebsd.org> <7mg0c05n3h.wl@waterblue.imgsrc.co.jp> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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). -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?3B5439C2.9493996E>