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)

[Ian Stakenvicius]

Sent from an iPhone, sorry for the HTML...

> On Sep 19, 2015, at 7:30 AM, Alexis Ballier <aballier@g.o> wrote:
>
> On Sat, 19 Sep 2015 12:25:40 +0100
> Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote:
>
>> On Sat, 19 Sep 2015 12:08:21 +0200
>> Pacho Ramos <pacho@g.o> wrote:
>>> On the other hand, if we start always setting the available slots
>>> that we know to work, we can avoid this issue, and this is also
>>> completely future proof becase I don't think we can assume that
>>> package B will always work with the latest available SLOT package A
>>> can have in the future. Then, applying the same policy of we trying
>>> to set the versions in dependencies to the versions we know are
>>> compatible, we should do the same with the slot.
>>
>> You know, there's this thing called a :* slot dependency...
>> Originally, the intent was that any dependency which might match more
>> than one slot would explicitly use an operator, and that repoman
>> would enforce it.
>
> repoman warns when it *does* match more than one slot; maybe it should
> warn when it *might* ?
>

And how is repo man supposed to know that????  :)

I'm having a but of difficulty understanding exactly what the request is in this thread.  Rdeps of a package that is slotted (isn't SLOT=0) absolutely needs to specify slot or a :* operator.  But for all the packages that are SLOT=0, I do not think we should be specifying slot on all the rdeps just because some day we might add a new slot.  Especially since we might need to change both the old and new SLOT= when we do this.  

And I also see it perfectly acceptable to bump all rdeps when this needs to occur.  Although, if we fix "slot move" then this may be less necessary.

Now, adding a ":=" slot operator to rdeps when the package still just has a simple/single slot does seem fine to me and makes sense for future proofing.  I know some think this isn't a good idea as well though.