Re: [gentoo-dev] [RFC] Moving subslot-only virtuals to a separate category to reduce confusion

[Alec Warner]

On Sat, Jan 30, 2021 at 9:36 AM Michał Górny <mgorny@g.o> wrote:
>
> Hi,
>
> TL;DR: I'd like to move virtual/libjpeg, virtual/libudev and so on to
> another category (e.g. lib-sover/*) to make it clear that they are used
> for := deps and have valid use even with a single provider.
>
>
> Right now we have at least a few packages that provide more than one
> valid consumer-intended library, each with a different SOVERSION that is
> bumped independently.  To list a few examples:
>
> - media-libs/libjpeg-turbo: libturbojpeg.so.0, libjpeg.so.62
> - sys-apps/systemd: libsystemd.so.0, libudev.so.1
> - app-text/poppler: libpoppler.so.106, libpoppler-cpp.so.0, libpoppler-
> glib.so.8, libpoppler-qt5.so.1
>
> The problem is that the current subslot mechanism doesn't really provide
> for that.  Laying aside possible future EAPI extensions (that are
> debatable due to added complexity to an already complex syntax), there
> are three commonly used possibilities here:
>
> a. bumping subslot whenever any of SOVERSIONs change -- meaning possibly
> unnecessary rebuilds,
>
> b. using subslot for one of the SOVERSIONs and assuming the rest stable
> -- this is what we do for poppler, and it's mildly confusing,
>
> c. using additional packages to represent SOVERSION of individual
> libraries -- this is e.g. used for libudev or libjpeg.
>
>
> I'd like to discuss option c. in more detail.  Right now, we're creating
> additional packages in virtual/ category.  This was mostly fine,
> as the libraries in question (libjpeg, libudev) had multiple providers.
> However, now that we've removed the old media-libs/jpeg, people get
> the obvious idea that the virtual is no longer necessary -- except that
> it is!
>
> The rough idea is that the subslot of libjpeg-turbo is supposed to
> represent the ABI version of libjpeg-turbo -- that is actually rarely
> used.  On the other hand, the subslot of libjpeg is represented by
> virtual/jpeg.  So if your package is using libjpeg.so, it should :=-
> depend on the latter and not on the former.
>
> The problem is that this is confusing, and if somebody doesn't know
> the secret, he can easily consider the virtual obsolete and depend
> on the library directly.
>
> To make this SOVERSION-virtual concept more visible and easily
> distinguishable from regular virtuals, I'd like to propose that we start
> moving them into a dedicated category.  For example, 'lib-sover' comes
> to my mind.  While this ofc doesn't guarantee that people will do things
> right, it will at least make it clear that these packages are somewhat
> different from regular virtuals and hopefully avoid making wrong
> assumptions.
>
> WDYT?

I'm not sure I understand the problem with (a). But this is partly my
bias here. I expect to rebuild with Gentoo; often; its literally the
whole point. So when the developer community is like "Well we want
fewer rebuilds" I sort of scoff. "This is Gentoo, rebuilds are a
thing." I wish I was more in sync with the community on this ;(

For (c) I'd rather see something like a linter:
 - If I dep on libjpeg-turbo, raise a linter hint that says "hey if
this dep is for libjpeg.so, if you want that, swap this *DEPEND for
virtual/jpeg: read this wiki page for more information..."
 - Its not meant as a QA warning (the hint will not prevent submission
or block CI.)
 - But its a mechanization of this problem and solution. Instead of
reading some thread on -dev,  there is a tool to detect instances of
this problem, it tells you briefly what the options are, and links
somewhere for more information. This sort of thing is related to an
earlier -core thread about how to keep developers up to date..threads
like this are great but they are not a system.

In short, I don't think a package naming convention is sufficient to
achieve your goal of making this problem happen less often.

I also have no idea how often this problem happens today (and if we
can lint it, we can count those too.)
Is the problem even a big enough deal to do anything?

-A

>
> --
> Best regards,
> Michał Górny
>
>
>