On Tue, Nov 5, 2019 at 9:08 PM Randy Barlow
<bowlofeggs(a)fedoraproject.org> wrote:
> langdon wrote:
> > > * compat-libs (or compat lib style): not discoverable, name
> > > mangling
>
> Randy Barlow replied:
> > Yeah I don't love this either.
>
> I don't understand why people dislike compatibility libraries so
> much.
I'll qualify my position as not so much that I strongly dislike it, but
more that I would prefer if the package metadata could formally store
the data for me, rather than encoding it in the name.
When we encode it in the name, it's a convention, but when we store the
data in the package metadata it becomes a formal spec.
For example, in Gentoo the Python package is just called "python", and
because they know about slots, it is comfortable with me having several
of them at once:
$ equery l python
dev-lang/python-2.7.16
dev-lang/python-3.6.9
In Fedora, we obviously do this too, but we don't call the package
Python, instead calling it "python2" and "python3":
$ rpm -q python2
python2-2.7.16-2.fc30.x86_64
$ rpm -q python3
python3-3.7.5-1.fc30.x86_64
This isn't bad, per se, but I like the elegance of having the package
manager explicitly know that python-2.7.16 and python-3.6.9 are both
the same package, just different slots of it. I mean, obviously, it's
working out OK for us.
This feature of "slotting" multiple EVRs of the same name actually
already exists in RPM. DNF currently restricts this to packages that
contain one of the following provides:
* installonlypkg(kernel)
* installonlypkg(kernel-module)
* installonlypkg(vm)
* multiversion(kernel)
It's not terribly difficult to extend this functionality to apply more
broadly than kernels and VM images wrapped in RPMs. :)
--
真実はいつも一つ!/ Always, there's only one truth!