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.
