Date: Tue, 19 May 2009 11:43:07 +0200 From: Jan Henrik Sylvester <me@janh.de> To: Pav Lucistnik <pav@FreeBSD.org> Cc: cvs-ports@FreeBSD.org, Pietro Cerutti <gahr@FreeBSD.org> Subject: Re: [review] cvs commit: ports/math/libqalculate Makefile Message-ID: <4A127F2B.6050708@janh.de> In-Reply-To: <1242719584.93676.14.camel@pav.hide.vol.cz> References: 20090518182452.2B7F310656B4@hub.freebsd.org <4A11E1FE.9010601@janh.de> <1242719584.93676.14.camel@pav.hide.vol.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
Pav Lucistnik wrote:
> Jan Henrik Sylvester píše v út 19. 05. 2009 v 00:32 +0200:
>> Pav Lucistnik wrote:
>>> Pietro Cerutti píše v po 18. 05. 2009 v 18:24 +0000:
>>>> gahr 2009-05-18 18:24:36 UTC
>>>>
>>>> FreeBSD ports repository
>>>>
>>>> Modified files:
>>>> math/libqalculate Makefile
>>>> Log:
>>>> - Add dependency on math/libgmp4
>>>> - Bump PORTREVISION
>>>>
>>>> Reported by: Jan Henrik Sylvester <me at janh.de>
>>>> -LIB_DEPENDS= cln.5:${PORTSDIR}/math/cln
>>>> +LIB_DEPENDS= cln.5:${PORTSDIR}/math/cln \
>>>> + gmp.8:${PORTSDIR}/math/libgmp4
>>> Why are you adding a dependency on libgmp4, when this port is depended
>>> on already, indirectly, via math/cln ?
>>>
>>> This is unneeded in FreeBSD Ports.
>> I really would like to understand this.
>>
>> As far as I understand, if a shared library version is bumped -- for
>> example recently libgmp.so.7 was bumped to libgmp.so.8 -- all ports that
>> have gmp.7 listed in LIB_DEPENDS are changed to gmp.8 and have their
>> PORTREVISION bumped at the same time to trigger a rebuild of the package.
>>
>> Ports that depend on the library only indirectly are not bumped, since
>> it would be a waste to rebuild everything recursively. This can only
>> work, if all ports linking a library actually list that dependency as
>> there is no other way for someone bumping a shared library version to
>> know which packages actually link that library.
>>
>> In this case, /usr/local/bin/qalc from math/libqalculate linked
>> libgmp.so.7, but since the dependency was not listed, the PORTREVISION
>> was not bumped leaving the package broken.
>
> Your observation about the need to recompile packages is correct.
> But we cannot guarantee that all ports, that link some library, have it
> listed in LIB_DEPENDS, and, indeed, it is not a common practice.
> Imagine some complex ports having hundred of LIB_DEPENDS lines in their
> Makefile!
>
> Current practice of bumping PORTREVISION based on presence of
> LIB_DEPENDS line is insufficient.
>
> What we really need is a post-commit hook in portupgrade that would scan
> all binaries under /usr/local, and trigger forced rebuilds if anything
> links libraries from compat/pkg subdirectory.
There are ports that have explicit dependencies that could be omitted
because of indirect dependencies. From my experience, this cannot be
totally uncommon, since it happens only about twice a month that I find
something in compat/pkg that is really needed -- and most of these cases
are dependencies that are not required, but come from overenthusiastic
autoconf, or dependencies that are listed in the port but without
version. I have reported quite a few of these occurrences to port
maintainers and most have fixed the ports expect for a few that do not
believe in the PORTREVISION bumping, since it does not really solve the
problem.
Leftovers in compat/pkg being rather rare is the reason why I reported
these cases -- only 3 for libgmp, but this is 3 more than usual.
The real pain is portupgrade keeping all the .so.X.Y.Z libraries in
compat/pkg and all libraries from outside the standard path (like the
gcc43 ones). At the same time, libchk seems to ignore .so.X.Y.Z
completely. I have no clue how others deal with this problem.
With quite a few of my PORTREVISION-bump-missing reports being ignored,
I do not think there is general consensus how to deal with these issues,
but from my perspective as a user this is the most problematic part of
the ports system. (For example, the gnome updates always miss exactly 1:
x11-wm/compiz -- I got used to that.)
I do not know how to fix portupgrade, but there seems to be some
agreement that portmaster should be the future. For me, the ability of
portupgrade to use packages for updates is essential.
I guess I should post this to ports@, but answers there only showed me
that there even is no consensus how to deal with it now:
http://lists.freebsd.org/pipermail/freebsd-ports/2008-July/049348.html
(answer, but only for a special case)
http://lists.freebsd.org/pipermail/freebsd-ports/2009-January/052473.html
(not answered)
http://lists.freebsd.org/pipermail/freebsd-ports/2009-January/052100.html
(answers, but with different opinions)
Cheers,
Jan Henrik
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A127F2B.6050708>