On Sat, Jan 30, 2021 at 9:36 AM Michał Górny <mgo...@gentoo.org> 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 > > >
