Date: Sun, 27 Jan 2002 23:01:46 -0500 From: Tadayuki OKADA <tadayuki@mediaone.net> To: Alexander Leidinger <Alexander@Leidinger.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: <20020127230146.16179bd3.tadayuki@mediaone.net> In-Reply-To: <200201271253.g0RCrLr02030@Magelan.Leidinger.net> References: <20020126222231.1c336cf3.tadayuki@mediaone.net> <200201271253.g0RCrLr02030@Magelan.Leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 27 Jan 2002 13:53:20 +0100 (CET)
Alexander Leidinger <Alexander@Leidinger.net> 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.
> > i.e. PORTREVISION will be changed automaticaly whenever shlib version is bumped.
> > If you have to bump PORTREVISION manually, what's the point not to specify
> > shlib's version at the same time?
>
> Mikhail proposed to not add the library version if the port is able to
> use the new and the old lib. An user may decide to not use the new lib.
Adding IGNORE_SHLIB_VER or something will be enough.
> 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.
> 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.
You want every ports user to check the reason of the PORTREVISION bump
when he or she updates a installed port?
He may jsut want his installed package up-to-date.
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.
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?
# of course we can manage this with portupgrade - thanks to knu-san.
# but that's not the point.
> 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 don't buy the let-user-chose-shlib-version crap.
Optional knob will be good enough if it's really needed.
> >> 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
> >> 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.
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?
> >> 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.
Wow, that's user frendly too!
--
Tadayuki OKADA
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?20020127230146.16179bd3.tadayuki>