Date: Sun, 27 Jan 2002 13:53:20 +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: <200201271253.g0RCrLr02030@Magelan.Leidinger.net> In-Reply-To: <20020126222231.1c336cf3.tadayuki@mediaone.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 26 Jan, Tadayuki OKADA wrote:
[PROTREVISION of gnome ports may get bumped incorrectly]
> And I think there might be several gnome ports which use recursive dependency
> to get a shlib dependency which should've been explicit dependency.
I think this too, but I hadn't time to verify it (at the moment I have a
problem with galeon, buttons and textentry fields have irrationaly large
fonts, I've seen this already a while ago (again after an update of some
ports in the middle of the dependency chain)).
>> >> >> Sorry, I wanted to say: "If we decide to accept Mikhail's proposal, we
>> >> >> have the possibility to determine which port needs a PORTREVISION bump
>> >> >> just by looking at the dependency information."
>> >> > That's a possibility. Not the current implementation.
>> >> > The proposal is incomplete without the utility side changes.
>> >>
>> >> Sorry, but I can't see where Mikhail's proposal changes the behavior in
>> >> this regard. Can you please explain it to me?
>> > Previously you said 'we have the possibility'. It means we don't have it yet.
>> > There is no tool to detect a need of PORTREVISION bump just by the dependency.
>>
>> ---snip---
>> #!/bin/sh
> ....
>> done
>> ---snip---
> Thanks for your effort. But is this the possibility that you mentioned?
It's one possibility. A quick hack.
> 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.
> 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.
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.
As I understand Mikhail (and I may be wrong) he talks about features,
not about policy.
>> > It does violate Porter's Handbook.
>> > And it also breaks pkg_version and portversion's updates detection.
>> > # Those tools are written based on the assumption we observe Porter's Handbook.
>>
>> Not bumping PORTREVISION does this, yes. But Mikhail's proposal isn't
>> about bumping it or not.
> Think again. You bump PORTREVISION, but not specify the shlib version.
> What will happen? If there's old version of shlib installed,
> the port will pick it up, and newer version will not be installed.
Yes, this is what Mikhail wants.
> But the installed package will have bumped PORTREVISION.
> His porposal doesn't make sense if you bump PORTREVISION.
I'm not sure if you are mixing port and package here (sorry, it's not
clear for me).
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)).
If someone installed the new _package_, the package should requested the
installation of the lib because of the new PORTVERSION of it.
>> 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.
>> > so installed package A still depend on old version of libB.so.
>> > And new libB.so may include critical fix like security hole.
>>
>> 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.
>> 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)?
Bye,
Alexander.
--
It is easier to fix Unix than to live with NT.
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?200201271253.g0RCrLr02030>