improving vlc-devel

[Michael Johnson]

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
> 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 libx264.so.50 changes to libx264.so.99 (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 LibName.so instead of
> = LibName.so.LibVersion.
>
> 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
.LibVersion
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
  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 libx264.so.2,
update"

Why is this important?
- When User-X decides to run portupgrade he won't have any surprises like
missing libraries
   after the upgrade (ie: libx264.so.1). This assumes you don't use the
library backup
   feature in portupgrade, which isn't found in programs like portmaster
(AFAIK)
- 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
depends.

Michael

If you don't have an actual example of breakage from the changes I propose,
> please, just take my word for it...


        -mi
>