improving vlc-devel

Michael Johnson ahze at
Mon Feb 26 17:39:10 UTC 2007

On 2/26/07, Mikhail Teterin <mi+kde at> 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
> other
> = 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 changes to (I chose
> x264
> = since we patch it to control the LibVersion number to reduce the number
> of
> = rebuilds on VLC and mplayer)
> [...]
> = I'm open to a patch that makes VLC link to instead of
> =
> Michael, you are not even wrong... FreeBSD's run-time linker's behaviour
> and
> port's dependencies are different domains and have little to do with each
> other.

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
- I update x264 to 20070202 which bumps the LibVersion, with
- I bump PORTREVISION in vlc, mplayer, etc to chase LibVersion bump in the
Makefile and in the
  actual program.
- User-X updates his ports tree but doesn't run portupgrade and wants to
install vlc
  This way there will be an error saying "hey we can't find,

Why is this important?
- When User-X decides to run portupgrade he won't have any surprises like
missing libraries
   after the upgrade (ie: This assumes you don't use the
library backup
   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 mailing list