From owner-freebsd-ports Mon Jan 28 3: 6: 7 2002 Delivered-To: freebsd-ports@freebsd.org Received: from mailout04.sul.t-online.com (mailout04.sul.t-online.com [194.25.134.18]) by hub.freebsd.org (Postfix) with ESMTP id 5891437B416 for ; Mon, 28 Jan 2002 03:05:54 -0800 (PST) Received: from fwd03.sul.t-online.de by mailout04.sul.t-online.com with smtp id 16V97a-0005hS-0f; Mon, 28 Jan 2002 11:34:42 +0100 Received: from Magelan.Leidinger.net (520065502893-0001@[217.83.27.136]) by fmrl03.sul.t-online.com with esmtp id 16V97Y-0b4ZofC; Mon, 28 Jan 2002 11:34:40 +0100 Received: from Leidinger.net (netchild@localhost [127.0.0.1]) by Magelan.Leidinger.net (8.11.6/8.11.6) with ESMTP id g0SA3Jw02159; Mon, 28 Jan 2002 11:03:20 +0100 (CET) (envelope-from netchild@Leidinger.net) Message-Id: <200201281003.g0SA3Jw02159@Magelan.Leidinger.net> Date: Mon, 28 Jan 2002 11:03:17 +0100 (CET) From: Alexander Leidinger Subject: Re: cvs commit: ports/graphics/gd Makefile pkg-comment To: tadayuki@mediaone.net Cc: tadayuki.okada@windriver.com, mi@aldan.algebra.com, will@csociety.org, freebsd-ports@FreeBSD.ORG In-Reply-To: <20020127230146.16179bd3.tadayuki@mediaone.net> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=US-ASCII X-Sender: 520065502893-0001@t-dialin.net 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 On 27 Jan, Tadayuki OKADA wrote: >> > I thought you were talking about more automated process. >> >> We could generate (like INDEX) a dependency tree of the complete ports >> collection and write a set of tools which operates on it. > Maybe. But it's not the *current* implementation. No, but that isn't important. - We have a way to determine the dependend ports. - We could make the implementation of Mikhail's proposal depend on the above mentionel toolset. >> He doesn't propose to not readd the library version (or an usefull >> regex) in cases it may make sense (even if the port may be able to use >> the old version). It's up to the maintainer of the port to use the >> library version feature in a way he thinks is best for the users of the >> port. > I don't think it's for user. > It's only for committer or maintainer. - Port A doesn't break at a library version bump port B. (this makes users happy) I've stumbled several times over updates of ImageMagic with library version bumps. The only reason to install the new version was because of updated ports which depend on the new library but don't use features of the new library (so it would be ok to have a regex for this port, which specifies the lowest possible library version which would be ok to have a working port). If I care about the version of ImageMagic, I use pkg_version or look at the cvsup log. For this particular case (to which Mikhail referred already as an example) it is less work for an user if we have such a feature. - The maintainer has only to bump the PORTREVISION to have DTRT package builds on bento. (less work to do, he hasn't to change the library version; IMHO not very important) >> If someone installed the new _port_ because of the PORTREVISION bump but >> not installed the new lib, he explicitely decided to do so (if he know >> about the PORTREVISION bump he should also know about the PORTVERSION >> bump of the lib (I think it's save to assume a correlation of a library >> version bump and a PORTVERSION bump)). > There are several reasons to bump PORTREVISION. Yes, and you picked one reason: a library version bump of a port in LIB_DEPENDS. > You want every ports user to check the reason of the PORTREVISION bump > when he or she updates a installed port? No, but if he cares about revision bumps, he also cares about version bumps. So he will update the port with the version bump too. Updating the ports tree by hand isn't an easy task, so I asume most users will use portupdate. If they don't use portupdate and don't update by hand, the have a lot of installed ports which only differ in the version number (only looking at /var/db/pkg). In this case they have trouble with programs with dependencies on various libraries. Mikhail's proposal is beneficial for this kind of users because less additional library versions (-> less trouble) get installed. > He may jsut want his installed package up-to-date. So they use pkg_version, read cvsup/cvs-all logs and/or use portupdate. No need to care about them, they will either DTRT (portupdate case) or they are used to breakages (e.g. if they update ports in the wrong order). > port A got PORTREVISION bump. port B got PORTVERSION bump with new shlib > major version. He decided to update both port A and port B. > He updated port A first, because he knew if A depends on the new version > of libB.so, 'make install' for port A will install new port B first. See above. IMHO this (filling /var/db/pkg with ports which only differ in the version) is bad habit. Such users will see unexpected behavior sooner or later. I always wanted to have a feature which tells the user that he already has an installed port with a different version number. One should first update dependencies if he (or a port) really needs the new version. > But if port A doesn't specify libB.so's version, his assumption will fail. > Now he has to check the dependency first when he upgrades installed ports. > Is this really an improvement? IMHO: Yes, definitivley. > # of course we can manage this with portupgrade - thanks to knu-san. > # but that's not the point. It's the only way someone without knowledge about the internals of the ports collection is able to update ports in a safe way. And judging based on messages in de.comp.os.unix.bsd I'm able to say that it is used a lot and every user is happy because he now can easily update ports and doesn't have trouble because of multiple versions of the same library. >> If someone installed the new _package_, the package should requested the >> installation of the lib because of the new PORTVERSION of it. > True. But when you have to bump PORTREVISION manually, > what's the point not to specify the shlib version really? I have no point for the maintainer side of the view. The user side is explained above. > I don't buy the let-user-chose-shlib-version crap. > Optional knob will be good enough if it's really needed. If I only can vote between "no such feature" and "optional knob" I vote for "optional knob". >> >> Just because port B is updated this doesn't mean I have to update it. >> > This shouldn't be default. If we want such behavior we should add >> > a knob IGNORE_SHLIB_VERSION or something. >> >> This may break explicit SHLIB_VERSION dependencies because of API >> changes. At least there has to be a way to mark ignorable shlib version >> specifications if something like that will get implemented. > It doesn't need to be used for every port. > It can be used instead of his proposal like this: > .if defined(IGNORE_SHLIB_VER) > LIB_DEPENDS= jpeg:${PORTSDIR}/graphics/jpeg \ > png:${PORTSDIR}/graphics/png \ > freetype:${PORTSDIR}/print/freetype2 > .else > LIB_DEPENDS= jpeg.9:${PORTSDIR}/graphics/jpeg \ > png.5:${PORTSDIR}/graphics/png \ > freetype.8:${PORTSDIR}/print/freetype2 > .endif What if this port only works with freetype library versions greater than 4? >> >> How do you expect this to work if the library version of port B did not >> >> get updated when a security hole is fixed? >> > Think again. This is too easy. >> >> I just wanted to show that a library version bump is independend of the >> kind of bugfixes. > shlib's major version bump is exceptional because if you don't rebuild > the application which links against the library, the application won't > get the bug fixes how many times you update the libray. True, except you make a symlink for the new version (which is in 99% of the cases something one should never do). But unfortunately not every library version bump contains bugfixes or ABI changes :-(. You are making valid points here, but if a program really depends on such bugfixes, the maintainer has to specify the library version in the port. You are talking about policy here, and I don't want to talk about policy at the moment, I want to talk about features. > If the major version number is unchanged, you don't need to rebuild > the application to use the updated libray. > This is why we care about shlib's major version bump, isn't it? Not every bugfix affects every user, but library version bumps with API changes affect them all. So if an user decides to not update a particular library (berhaps because he has an application which depends on a feature which got removed from the library) he should be able to use programs which also work with the installed version of the library. If an user needs the bugfix, he has to update the application, and because of portupdate this isn't very hard. >> >> The "@pkgdep" line in packages contains ${PORTNAME}-${PORTVERSION}, so >> >> packages aren't affected. >> > So you want 'Joe user' to check '@pkgdep' line. That's user frendly! >> >> No, I want to have the pkg_* tools to handle this. Isn't this the case >> already (I really don't know, I always install ports instead of >> packages)? > 'pkg_info -r' shows the dependency. > So if I want to check the availability of the update, > I have to download the package and use pkg_info to the installed package > and the downloaded package to compare the dependency. I was thinking more about pkg_add which should check for already installed packages with older version numbers and requests a force option to install the package if the version number of a dependency is outdated. Ports are different from packages, so IMHO it would be ok to have different policies for ports and packages. The packages at bento are compiled agains specific versions of libraries, so forcing the user to have specific versions of dependend packages makes IMHO sense... but I'm talking about policy now, not about features. Bye, Alexander. -- The three Rs of Microsoft support: Retry, Reboot, Reinstall. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message