Re: [gentoo-dev] Re: Adding slot and subslot deps to others' packages

[Michał Górny]

Dnia 2014-03-03, o godz. 03:04:41
Michael Palimaka <kensington@g.o> napisał(a):

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

Just to be clear, I'm not going to revbump the packages now. I'd like
to fix all the dependencies early enough so that we wouldn't have to
revbump them when we introduce compat slots.

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

I want to do this *before*, for all potential packages. That is, just
fix all the stuff at once instead of fixing again and again every time
a new library is modified.

Committing to CVS has more overhead than adding the slot. So it's
better to add slots to all deps rather than one-by-one.

-- 
Best regards,
Michał Górny