On 6/08/2013 01:07, Rich Freeman wrote:
I suspect most maintainers would rather upgrade their package once to
EAPI5 and not keep checking back every month to see if there is a new
opportunity to add another slot operator dep. If maintainers don't
add them up-front even with the deps don't support them, chances are
they'll never add them.
Historically, I have seen library maintainers asking consumer
maintainers to add the subslot operator, where appropriate, after
correctly implementing the subslot.
How often does this situation even come up? If 9/10 times the
libraries are set up as maintainers expect them to be, it is probably
better to deal with the odd unnecessary rebuild until somebody spots
it, rather than going without support for slot operator deps.
With respect, "good enough" is not a very high standard to aim for. In
my opinion, adding unnecessary subslot dependencies is no different to
adding overly-wide dependencies.
We already have preserved-libs to prevent breakage. Subslots should be
an improvement on this, not causing a regression.