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:08 PM, Pacho Ramos wrote:


Thanks for the thread, but I have a small remark...


>
> With we trying to move to finally disable dymamic-deps and stop relying
> on them completely, an old problem will be a bit more noticeable now:
>
> - Tons of package RDEPEND on A
> - Long time after that, A starts to have a new SLOT
> - As most reverse deps need to be ported, we need to fix it
> retroactively to request the old slot that is known to work.
>
> Currently, we can see how most of us try to go as quick as possible to
> fix the dependencies retroactively setting the proper slot but this
> relies on dynamic-deps, if this feature gets disabled, we will need to
> make revbumps for all of them and people will need to rebuild all the
> reverse deps. This can be really problematic as some of this libs are
> used by a ton of packages... I can think on recent examples like
> gstreamer, gtk+, glib... for example a few days ago we needed to adapt
> reverse deps to the inclusion of a new gtk-sharp slot.
>

This sounds a little bit like you are suggesting: "fix" all of the
dependencies in-place before dynamic deps gets turned off. Please don't
do that. It already affects portage users who have turned them off and
paludis users... which leaves them with blockers and weird dependency
errors. It also affects those that DO use dynamic-deps, since they don't
work consistently (which is the whole point of turning them off).

Having as little RDEPEND in-place changes in the current ebuild tree as
possible is a _requirement_ for us to turn dynamic deps off. So it makes
sense to start right now.

> 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.
>

Hmm, you are suggesting to do this even for packages that only have one
SLOT anyway? I'm really not sure about this. Depending on the
SLOT-naming-scheme that will be introduced it may require massive
changes as well. It's hard to look into the future. I personally think
it is enough to do that for multislot packages.