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)

[hasufell]

On 09/19/2015 12:51 PM, Pacho Ramos wrote:
> 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
>
>

If you do

app-misc/foo:0

in every package and then app-misc/foo _drops_ SLOT 0 and instead
introduces SLOT 12.4 and SLOT 15.6, then that won't save you anything.
The same if it only renames the current SLOT, without actually
introducing another one... in which case you get even more work to do.

I'd say: if there is only one SLOT, don't make any assumption about it,
unless the SLOT is documented and expected to get additions (as it was
for gstreamer, but you can't assume that's the same story for everything
else).