Date: Mon, 26 Feb 2007 13:00:36 -0500 From: Mikhail Teterin <mi+kde@aldan.algebra.com> To: "Michael Johnson" <ahze@freebsd.org> Cc: multimedia@freebsd.org, mezz@freebsd.org Subject: Re: improving vlc-devel Message-ID: <200702261300.37063@aldan> In-Reply-To: <b2203fed0702260939q2cee4a88ja1e82b853b085eb6@mail.gmail.com> References: <200702260942.27062@aldan> <200702261157.27266@aldan> <b2203fed0702260939q2cee4a88ja1e82b853b085eb6@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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:
= 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.
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.
Yours,
-mi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200702261300.37063>