That ole Livna Problem/That ole VLC Problem

[Les Mikesell]

Michael Schwendt wrote:
>> Or even if
>> your application puts your library location first in a search path?
> 
> That *is* possible already, but requires lots of extra efforts at the
> packaging-front. And you don't want per-application local libraries
> instead of system libraries, do you?

If different ones are necessary to work, then of course I want different 
ones.  And if they weren't necessary...err.. why did we have this confict?

>>> Notice that several libraries and applications can even be built with
>>> a different feature-set.
>> Which is why multiple versions should be expected to co-exist.
> 
> The howto that can be applied to a large-scale packaging project like
> Fedora is missing. You don't want extra burden for volunteers with
> questionable or no benefit.

The process is understood within the fedora packaging project.  The 
problem is that, by policy in some cases, by law in others, and just by 
not being omnipotent in yet others, they don't include everything people 
want to run within the project.  And even as they include more stuff 
within the project itself either they have made no effort to coordinate 
contents with the repositories that had those packages previously and 
still supply them, or those efforts have failed.  Livna is something of 
an exception since they have never replaced any core/extra packages.

>>> Even multiple major releases of libraries
>>> cannot coexist peacefully, if not all packagers take extra (sometimes
>>> huge) efforts to avoid conflicts between data/doc/development files,
>>> and e.g. package them as "libfoo2" and "libfoo3".
>> Doesn't that tell you something?
> 
> Yes, it tells me a lot, but that is beyond the scope of this thread.

You stated a problem and it's solution.  But you are right that this 
thread probably isn't going to lead to a solution actually happening.

-- 
   Les Mikesell
    lesmikesell at gmail.com