On 03/02/2014 07:37 PM, Michał Górny wrote: > Hi, > > Few months ago I have written a small FAQ on how to use slots > and subslots for library dependencies properly [1]. However, today > I see that most of the developers didn't care to properly update their > packages and when I introduced binary compatibility slot in libgcrypt, > I had my hands full of work fixing the mess for a single package. > > Honestly, it's PITA to update and commit a few dozen ebuilds just to > modify a single dependency. Plus sometimes portage's dynamic-deps > no longer work so I'd have to revbump all the packages as well to > be 100% correct. And the sole fact that I'm fixing just one dep when > there's a dozen libraries more that may need fixing in the future... Please carefully consider whether a revbump is unconditionally required for every situation.
Pinning a dependency to SLOT 0 will be picked up by dynamic-deps, and if the user has it turned off it is likely that more building will be caused by the rebuilds versus the new binary compatibility slot. dynamic-deps does not apply to the subslot dependency operator, but revbumping to add it will just cause the user to have to build the package twice - once for the revbump and once when the subslot changes. > > So, I'm asking: would you mind if I started taking random packages > and updating the library dependencies (whenever they are clear) to use > slot :0 (in EAPI 1..4) and :0= (in EAPI 5) as appropriate? > > [1]:http://article.gmane.org/gmane.linux.gentoo.devel/88541 > For adding an explicit slot after a binary compatibility slot is introduced, I think that is fine. I have been doing that for virtual/jpeg as I come across them (AFAIK no effort was made to fix this when it was introduced) and I have never had any complaints.
