[review] cvs commit: ports/math/libqalculate Makefile

[Jan Henrik Sylvester]

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