Date: Mon, 28 Jan 2002 11:03:17 +0100 (CET) From: Alexander Leidinger <Alexander@Leidinger.net> To: tadayuki@mediaone.net Cc: tadayuki.okada@windriver.com, mi@aldan.algebra.com, will@csociety.org, freebsd-ports@FreeBSD.ORG Subject: Re: cvs commit: ports/graphics/gd Makefile pkg-comment Message-ID: <200201281003.g0SA3Jw02159@Magelan.Leidinger.net> In-Reply-To: <20020127230146.16179bd3.tadayuki@mediaone.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200201281003.g0SA3Jw02159>