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@xxxxxxxxx
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
