ahze at freebsd.org
Mon Feb 26 17:39:10 UTC 2007
On 2/26/07, Mikhail Teterin <mi+kde at aldan.algebra.com> wrote:
> On Monday 26 February 2007 11:13, Michael Johnson wrote:
> = That's not the reason we use LibName.LibVersion in VLC. VLC and many
> = programs hard link to LibName.LibVersion, we keep the LibVersion in
> there so
> = it reduces the amount of bug reports we get.
> = Here is an example if libx264.so.50 changes to libx264.so.99 (I chose
> = since we patch it to control the LibVersion number to reduce the number
> = rebuilds on VLC and mplayer)
> = I'm open to a patch that makes VLC link to LibName.so instead of
> = LibName.so.LibVersion.
> Michael, you are not even wrong... FreeBSD's run-time linker's behaviour
> port's dependencies are different domains and have little to do with each
I know they are different, but here is an example in why I like using
with the Makefile.
- User-X has x264-20061010 installed with libx264.so.1
- I update x264 to 20070202 which bumps the LibVersion, with libx264.so.2
- I bump PORTREVISION in vlc, mplayer, etc to chase LibVersion bump in the
Makefile and in the
- User-X updates his ports tree but doesn't run portupgrade and wants to
This way there will be an error saying "hey we can't find libx264.so.2,
Why is this important?
- When User-X decides to run portupgrade he won't have any surprises like
after the upgrade (ie: libx264.so.1). This assumes you don't use the
feature in portupgrade, which isn't found in programs like portmaster
- This helps enforce people are using the latest "Supported" version of a
port. This is
especially important when you're dealing with a port with so many
If you don't have an actual example of breakage from the changes I propose,
> please, just take my word for it...
More information about the freebsd-multimedia