improving vlc-devel

[Michael Johnson]

On 2/26/07, Mikhail Teterin <mi+kde at aldan.algebra.com> wrote:
>
> On Monday 26 February 2007 12:39, Michael Johnson wrote:
> = 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"
>
> Right here you _needlessly_ broke things for the user... Why? You try to
> justify the breakage below:


no, not needlessly, I want the port to be broken if they want to build with
an
older library. For things like x264 which almost always requires patches due
to API changes, this helps assure people are using the right version.

= 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)
>
> Wrong -- the dependency tracking for a port being installed records the
> package which ACTUALLY INSTALLED the library dependant upon, and NOT the
> package which WOULD'VE INSTALLED it, if all packages were built from the
> current ports tree. This has been the case for at least 3 years now --
> maybe
> 4... So, no "surprises" either way.


Yeah, you're right there. but I still don't understand why changing 2 lines
instead of
just 1 is important. Give me a better example in why you think this is so
important =)


It works like this:
>
>         . Port moo says:
>                 LIB_DEPENDS=    meow:${PORTSDIR}/woof/meow
>         . bsd.ports.mk runs `ldconfig -r | fgrep meow', finds the library
>           (such as /usr/local/lib/libmeow.so.X, for example)
>         . bsd.ports.mk uses `pkg_info -W /usr/local/lib/libmeow.so.X' to
>           find, which package installed it
>         . THAT package is recorded as a dependency for moo.
>
> The above WORKS. If, however, moo recorded an explicit X:
>
>                 LIB_DEPENDS=    meow.X:${PORTSDIR}/woof/meow
>
> the build BREAKS should meow.Y be installed (with Y being either above OR
> below X). How can such breakage be deemed "beneficial" is beyond me -- it
> serves no good purpose and does not help avoid any future problems to
> justify
> the inconvenience...
>
> That explicit X should never be specified -- unless there is a good
> reason,
> such as a different API (which is typically caught by the port's own
> configure anyway).
>
> FYI, the X can be a regular expression, giving further flexibility WHEN
> NEEDED. For example:
>
>         LIB_DEPENDS=    meow.[1-36-9]:${PORTSDIR}/woof/meow
>
> But please, stop using it gratuitously...
>
> = - 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.
>
> This last paragraph does not make sense to me. General words and imaginary
> benefits are presented as outweighting the concrete problem of being
> unable
> to install vlc without also rebuilding mplayer (in your examle).
>
> The "latest supported" is a non-argument -- the earlier-mentioned
> "chasing" of
> the shlib major numbers is done without any testing and verification
> beyond "it compiles", so let's not pretend otherwise. If anything, an
> earlier
> version of, say, libx264 is MORE likely to work :-) So a user, who has it
> already, should not be FORCED to rebuild.


I'd agree with this more if we had a branched ports tree (stable and current
trees)
like many other projects have.

Michael

Yours,
>
>         -mi
> _______________________________________________
> freebsd-multimedia at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-multimedia
> To unsubscribe, send any mail to "
> freebsd-multimedia-unsubscribe at freebsd.org"
>