Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?

[Rich Freeman <rich0@gentoo.org>]

On Sun, Dec 8, 2013 at 6:57 PM, Patrick Lauer <patrick@gentoo.org> wrote:
> On 12/09/2013 12:54 AM, Tom Wijsman wrote:
>>
>> One thing that directly comes to mind is that dependencies that have no
>> SLOT="0" ebuild present would need us to manually specify a specific
>> SLOT; given that this is a not so common situation, the amount of
>> commits needed here is low.
>
> And now you make updating a lot more fun, because slotted packages need
> to be explicitly changed if there's a new slot happening. Just to hide
> your own laziness.

Frankly, your tone is rude here.  Don't personalize things.  The goal
is to eliminate non-value-added work.  If a change makes work for
others that should be pointed out.  If a change saves somebody time,
that isn't "laziness."  Work isn't a virtue - accomplishing something
is.  Discuss the merits of the proposal, and don't debate the morals
of the person making the proposal.

Second, I'm not sure exactly what you're trying to say here.  Slotted
packages don't need to be changed under the proposed approach any more
than they otherwise would.  If you have SLOT=0 of libfoo and want to
introduce SLOT=1 it is the same amount of work for the libfoo
maintainer either way.  The only difference is that if half the tree
depends on libfoo and breaks with libfoo:1 then there are a bazillion
failures all the sudden.

If you meant that packages that depend on slotted packages need to be
changed, then that isn't really correct either.  If a package depends
on libfoo:0 instead of libfoo:*, it will work just fine when libfoo:1
is introduced - it will just continue to pull in libfoo:0.  Then over
time maintainers can test and add an || dep for libfoo:1 and the
package will work with either.

The status quo requires the libfoo maintainers to do a ton of work to
get everybody to change their deps before introducing a new slot.
Either that or they do what everybody else apparently does and not use
slots at all, just creating libfoo2.  Well, if you can't reliably
create new slots for dependencies, then what is the point of having a
syntax for slot dependencies in the first place?

On IRC there was some discussion and it may make sense to not make the
default :0 (or :0=), but rather to just not have any default in a
future EAPI - every single dependency line would therefore contain a
slot.  I'm not convinced wildcards should even be allowed - the whole
point of introducing new slots is that the new version may not be
compatible, so how can you say in advance that any slot is acceptable?
 If the new library is API-compatible then it should just be a new
subslot in the same slot, and if it is ABI-compatible then it should
be in the same subslot.  The whole point of subslots is to handle
packages that have API breaks, and I don't see how wildcards against
future versions not even written yet can be appropriate there.  The
only thing that it does is saves maintainers the trouble of looking up
what slots the package was actually tested against, which sounds a bit
like a certain word that starts with l...  :)

Rich