shlib majors (Re: improving vlc-devel)

Mikhail Teterin mi+kde at aldan.algebra.com
Mon Mar 5 03:02:22 UTC 2007


On Sunday 04 March 2007 15:11, Ulrich Spoerlein wrote:
= > Doing so _knowingly_ is simply capricious...
= 
= There is one advantage I see (omitting the library inter-dependance
= thingy): Once the shared lib version is bumped, all dependant ports have
= to be rebuild (relinked).

WHY? This is the core of the disagreement, I feel. I may be perfectly fine
with an earlier version of libfoo, which 15 of other installed packages are
using.

I should not be _forced_ to upgrade foo (and those 15 other ports), if I 
updated my ports tree and wish to install the 16th foo-using port (bar). Not unless bar _really_ needs an updated version of foo.

= In a perfect world, everybody would be using portupgrade -rf libfoo to
= update a library. In our real world it is not so. By hardcoding the lib
= number we intentionally break the automated build system (tinderbox), thus
= reminding us, that we should probably bump the portrevision so people
= rebuild all required ports, even if they only use portupgrade -a.

What you also "intentionally break", is everybody's install -- they can't add a port from an updated tree without first updating a bunch of other ports. Portupgrade makes this _easier_ (if nothing breaks, that is), but not _faster_.

Automated tinderboxes should use other means of dependency tracking (if they
really need it at all -- it seems, complete rebuilds simply run as often as the hardware allows). Something based on the all-depends-list target would be both more reliable and not break users' setups.

This is quite obvious, but continuous nit-picking leaves people with shorter attention spans feel, the issue is still "unresolved" or something...

	-mi


More information about the freebsd-multimedia mailing list