Date: Fri, 25 Jan 2002 12:23:25 +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: <200201251123.g0PBNQu28749@Magelan.Leidinger.net> In-Reply-To: <20020125030717.62e1cf65.tadayuki@mediaone.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 25 Jan, Tadayuki OKADA wrote:
>> On 24 Jan, Tadayuki OKADA wrote:
>> >> 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 ignore it, you do bump PORTREVISION as it says, right?
When I'm aware of a change which has to result in a PORTREVISION bump,
yes.
>> >> >> 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?
> 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
if [ -z "${1}" ]; then
echo 'You have to specify a portname'
exit 1
fi
hardwired='all'
# hardwired='package'
for port in */*; do
if [ -f ${port}/Makefile ]; then
if (cd ${port} && make ${hardwired}-depends-list | grep -q ${1})
then
echo ${port}
fi
fi
done
---snip---
You have to be in ${PORTSDIR}, the script prints every port which
depends directly and indirectly on the port you specify at the command
line.
If you just want the ports which depends directly you have to just use
the second 'hardwired' line.
Note, this is just a quick hack, I may have overseen something in
bsd.port.mk.
> Without such tool, port A's PORTREVISON will not be bumped.
You rely on the breakage of a port to do this? Why not recursivly grep
through every Makefile for ${PORTSDIR}/category/port? I'm sure there are
people out there, which updated most of the dependencies before these
ports breaked.
> 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.
>> >> 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).
> Yes, with PORTREVISION bump.
>
>> Mikhail's proposal changes this to: Update the port Makefile when the
>> API of the library changes.
> Yes. i.e. no PORTREVISON bump for no API change.
>
>> So this proposal is an improvement, because it breaks ports less often
>> and reduces the load for the ports team.
> And it won't complain when port A is built with old version of libB.so,
> despite the avalability of new port B.
Just because port B is updated this doesn't mean I have to update it.
And if port A relies on a feature of the new version of port B, port A
has to specify the version of port B it relies upon. Mikhail doesn't
want to forbit this.
> And there will be several packages they have exactly same name and version,
> but they depend on different major version of shlib.
Not if the PORTREVISION gets bumped. Bumping the PORTREVISION is
orthogonal to Mikhail's proposal.
> i.e. their binaries are different.
> How can 'Joe user' know a need of update when the latest package has
> exactly same version with the installed one.
>
> And one more example (how many times do I have to explain this?):
> package A and package B are installed.
> port B get shlib major version bump.
> install new package B.
> pkg_version or portversion can't detect needs of update for package A,
> because A's PORTREVISON is not bumped.
Then the maintainer of port A and/or the maintainer of port B did
something wrong. A PORTREVISION bump is independend of Mikhail's
proposal.
> 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?
I don't want to talk more about security implications here, there are a
lot of other deficiencies in this regard which only an user (root) can
take care of. The security officers send notifications, this has to be
enough for the moment (and doesn't belong to Mikhail's proposal).
> Are these improvements for you?
The "@pkgdep" line in packages contains ${PORTNAME}-${PORTVERSION}, so
packages aren't affected.
>> 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.
> I'm not saying it changes runtime behavior.
> What I'm saying is it breaks user's proper update process.
It doesn't, PORTREVISION updates aren't affected, see above.
Bye,
Alexander.
--
Intel: where Quality is job number 0.9998782345!
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?200201251123.g0PBNQu28749>