Bug 600020 – Force developers to specify the right SLOT variant on next eapi

• Product: Gentoo Hosted Projects
• Status: CONFIRMED ---

[Description Pacho Ramos 2016-11-16 16:52:02 UTC]

This is an old issue:
- Most dependencies are written without any slot information at all. This defaults to allowing any slot to provide the dep... but that is rarely valid.

This is happening really often (gtk+, glib, gstreamer, all QT stuff, giflib, libpng, openssl...), and I still need to fix from time to time deps of reverse tools relying on random lib because of this.

The main issue of this is that we are always needing to fix things once they break, this needs an amount of work that looks like we are also unable to handle (and, hence, we still have ebuilds with incorrect deps):
- We rely on no slot
- Some years later upstream decides to make big changes and, then, we need to introduce a new slot.
- We need to fix all reverse deps to force the usage of old slot until they are properly tested to work with newer too (this also needs revbumps for all of them for runtime deps, hence forcing users to rebuild lots of apps).

And this is going to happen forever as most of the libs will need a major bump sooner or later :/

There have been some suggestions trying to solve this "unpredictable" behavior:
https://archives.gentoo.org/gentoo-dev/message/c119c209c9b581deac0d6555b99d29e4

This was suggesting to "silently" default to slot 0 when nothing is specified... I do not care if that is your preferred solution... but I think that, if we are going to introduce this *in a new eapi* we should probably try to force people to set the proper slots for the deps (most of the times forcing the right slot, in other cases specifying the range of slots that work, in others setting :* if they think all slots are ok... that being not really common I think).

Thanks a lot