Re: [gentoo-dev] Always specify SLOT we know a package is compatible with (even if only one SLOT exists at the moment ebuild is added)

[Pacho Ramos]

El sáb, 19-09-2015 a las 12:51 +0200, Pacho Ramos escribió:
> El sáb, 19-09-2015 a las 12:40 +0200, hasufell escribió:
> > On 09/19/2015 12:36 PM, hasufell wrote:
> > >
> > >
> > > I personally think
> > > it is enough to do that for multislot packages.
> > >
> >
> > And afais repoman already emits a warning for those on EAPI=5.
> >
> Yes, I know... this is about always setting the SLOT we know it does
> work, even when only one SLOT exists (as the summary says) to prevent
> we need to constantly fix RDEPENDs of all reverse deps every time a
> new
> slot is added. This currently was a bit more "invisible" to users...
> but once dynamic-deps are disabled, people will need to rebuild ALL
> that reverse deps to get the proper (old) slot set in VDB.
>
> In summary, this is the first suggestion of:
> https://bugs.gentoo.org/show_bug.cgi?id=493742#c0
>
> That it will know much more visible as, for example, at the time
> gstreamer:1.0 was added, we were able to simply fix reverse deps to
> pull in the old slot they were still using, but now, in addition to
> that, people will need to also rebuild all the reverse deps for the
> same purpose. If, at the start, that packages would have the proper
> slot set that was working when the package was added/bumped, the deps
> would have being ok for the first time and, then, no update of the
> RDEPEND and no rebuild would be triggered
>
>

Another case that occurred just a few days ago: people needed to set
SLOTs to dbus-sharp reverse deps, and this problem appear again and
again because setting no slot at all and expecting that it will work
"forever" is not future proof at all... and that is the reason we are
constantly needing to fix all reverse deps after we notice that,
obviously, it's not common that the same package that was compatible
with slot 0 will start to be also compatible with any slots that could
be added in the future.

In the current way, we are always delaying the breakage until upstream
decides that it's time to break things and we start to need a new slot.

On the other hand it looks much better to me to keep being safe and fix
the deps to the ones that we KNOW ARE working ok. 

Well... I remember to still need to fix some ebuilds in the recent
months that were still pulling gtk3 because they didn't set any slot.