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? -- Best regards, Michał Górny
