Date: Thu, 24 Jan 2002 20:08:23 +0100 (CET) From: Alexander Leidinger <Alexander@Leidinger.net> To: tadayuki.okada@windriver.com Cc: tadayuki@mediaone.net, mi@aldan.algebra.com, will@csociety.org, freebsd-ports@freebsd.org Subject: Re: cvs commit: ports/graphics/gd Makefile pkg-comment Message-ID: <200201241908.g0OJ8Q101722@Magelan.Leidinger.net> In-Reply-To: <3C5022E4.4294D4F3@windriver.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 24 Jan, Tadayuki OKADA wrote:
>> >> > If you bump PORTREVISION, people can tell port A needs to be updated
>> >> > by pkg_version or portversion.
>> >>
>> >> Yes. But Mikhail doesn't talk about this. And it's possible with his
>> >> proposal too. We already have/generate dependency information in/for
>> >> the INDEX, so we just can use it to determine the ports which need an
>> >> PORTREVISION bump.
>> > Please send a patch or new utility which does this.
>>
>> It isn't common practice to bump the revision of dependand ports, see
>> below, so there isn't the need for such a tool at the moment.
> So you ignore Porter's Handbook?
No, I don't ignore it. I just commented on the actual practice (see my
png/gnome comment).
>> >> > If you don't specify the lib version, port A build may not break,
>> >> > so you are likely to forget PORTREVISION bump.
>> >>
>> >> Yes. That's true. But this isn't common practice. The actual common
>> >> practice is to not increment the PORTREVISION if a library increments
>> >> its version number (and you've got an explanation why).
>> > Who said the actual common practice is not to bump PORTREVISION?
>>
>> Sorry, I wanted to say: "If portA depends on portB and portB got a
>> PORTREVISION increment, then it is not common practice to also increment
>> the PORTREVISION of portA."
> I've never said port A's PORTREVISION needs to be bumped when
> port B's *PORTREVISION* is bumped. Please check the context again.
You didn't? Oops, I misunderstood you then. Sorry.
>> At least I have _not_ seen a PORTREVISION bump on a lot of gnome* ports
>> at the time the library version of libpng changed (and I had to
>> recompile a lot of gnome* ports to get my custom widget background
>> back).
> You don't need to bump PORTREVISION if a port depends on a shlib
> indirectly. Assume the dependency is port A -> port B -> port C,
> then port C's shlib major version is increased, port B needs
> PORTREVISION bump, but as long as port B is binary compatible with
> the previous version, port A doesn't need PORTREVISION bump.
I've already seen the opposide. I can't remember which port was
affected, but I had to recompile a lot of gnome ports, which didn't have
libpng in the dependency list directly (but indirectly).
>> And Mikhail's proposal is independend from this. It is not mutually
>> exclusive, so I don't see the problem you have with the proposal.
>>
>> >> And even if we decide to increment the PORTREVISION this isn't really a
>> >> strong argument as I already explained above.
>> > pkg_version is in the base system. portversion is part of portupgrade which
>> > is very popular tool these days.
>> > We don't have any tool other than these to detect which port to upgrade.
>>
>> 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?
>> Makhail's proposal doesn't change any run time behavior. It only changes
>> the compile time behavior if there are outdated ports installed. This
>> doesn't affect official packages.
> As I said, it breaks user side update process.
> How does a user know when package A is rebuilt with updated package B
> which bumps shlib major version and may include critical bug fixes
> without port A's PORTREVISION bump?
The actual way is to update the port Makefile when the library version
changes, even if the port is API compatible (only the ABI of the library
changed).
Mikhail's proposal changes this to: Update the port Makefile when the
API of the library changes.
So this proposal is an improvement, because it breaks ports less often
and reduces the load for the ports team.
I don't see where the run time behavior changes, only the compile time
behavior changes. If I'm wrong here, please tell me where I don't get it
right.
>> The proposal is only benefical for a small part of the userbase, e.g.
>> for every ports commiter who knows what he does. "Joe User", which uses
>> official packages, is not affected.
> So you don't care about ports user?
I care about them, but I don't see where the average ports user can have
a problem. Can you please describe it to me?
>> > Unless we have other tool to do this, we should keep ports complient with
>> > these tools.
>>
>> Mikhail's proposal doesn't break them.
> Yes, it does.
How? Can you please give me an example?
Bye,
Alexander.
--
To boldly go where I surely don't belong.
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?200201241908.g0OJ8Q101722>