On Wed, 21 Jan 2015 11:15:04 +0100
Michał Górny <mgo...@gentoo.org> wrote:
> Dnia 2015-01-21, o godz. 11:05:01
> Alexis Ballier <aball...@gentoo.org> napisał(a):
>
> > > > > 2. Subslots work correctly. Rebuilds are forced when the
> > > > > chosen library is upgraded. Moreover, USE flag change causes
> > > > > a rebuild when user decides to change the ffmpeg provider.
> > > >
> > > > No offense, but this argument is complete crap. You should
> > > > rather fix portage bugs than propose to introduce tree-wide
> > > > changes to hide them... More precisely: || ( a:= b c:= d ) is
> > > > perfectly defined (in the "what it means" sense, not in PMS
> > > > sense). When the package is built, if 'a' is satisfied then a
> > > > (and its subslot) is added to the subslot list of the package;
> > > > ditto for c. You end up with a list of subslot deps, that you
> > > > can store in vdb or whatever, and use that to decide when to
> > > > rebuild the package.
> > >
> > > Following a specification is not a bug. I could argue here a lot
> > > but... just implement it. And return to us when you do. We had an
> > > item for this for EAPI 6, and it was removed because nobody
> > > volunteered to implement it. In fact, nobody even were able to
> > > fully specify what it should do... but if you want to discuss
> > > that, please start a new thread, possibly at the -pms list.
> >
> > Above is a simple algorithm that works in all cases. What you're
> > asking me to do is "go beg pms list to allow something they don't
> > want because the subslot/:= spec was poorly written and thought
> > of". I already gave you the solution, don't count on me for the
> > administrative work :=) (NB: everytime I tried to improve/fix
> > something in pms I failed miserably, so that I have no other choice
> > but giving up on this, check bgo)
>
> No, it works in the one case you thought of. Two quick issues:
Ok, so first thing: You are the one writing about putting || in
"effective deps" (whatever that means), for me := deps that apply when
the package is installed is just a list created when the package is
built: no ||, no use conditional, and with subslots instantiated.
> 1. What does || ( a b:= c:= ) mean? i.e. only some having subslots.
This makes sense only when in DEPEND+RDEPEND (because of the :=), so
apply this (mostly copy/paste) for all such deps:
for a in 'a' 'b' 'c':
When the package is built, if 'a' is satisfied and has a :=
dep then 'a' and its subslot is added to := deps list for the
installed package
As for the meaning, it uses all of a, b and c that are available at
buildtime and at least one of them must be present.
for 'b' and 'c', the := dep description/meaning from pms applies.
> 2. What does || ( a:= b:= ) mean when a and b can be both installed?
Ditto.
> Adding a very specific PMS rule for two packages doesn't sound like
> a very good idea to me.
I agree but I don't think it is that specific.
> > Moreover, when I bumped ffmpeg subslot, portage did rebuild all
> > those packages with || ( := := ) deps properly for me. So, you'll
> > have to be a bit more specific on what goes wrong than 'broken ||
> > ( libav:= ffmpeg:= )'...
>
> I already told you that before. Try switching from ffmpeg to libav,
> and see what mess it causes. I'll summarize it for you:
>
> 1. if you have dynamic-deps enabled, portage will want to install both
> ffmpeg (because of :=) and libav (because of ||). The effective
> deps will look like:
>
> || ( ffmpeg:0/51= libav ) ffmpeg:0/51=
with a separate := deps list, you have 'ffmpeg:0/51=' in the list; you
notice ffmpeg subslot has changed from '0/51' to '' (since it is not
installed anymore) so trigger the package for rebuild and use the ||
( ffmpeg:= libav:= ) dep (which I assume works fine since that's what
happens when you install the package). the bug here is that portage
uses a crafted (r)depend string for reinstall, instead of the ones
from the stock ebuild from either vdb or the portage tree.
> 2. If you have dynamic-deps disabled, portage will happily switch impl
> without rebuilding revdeps (breakage). Afterwards, it will allow
> upgrading the other dep (libav) without rebuilds. The effective deps
> will look like:
>
> || ( ffmpeg:0/51= libav )
this is also solved by having a separate := dep list in vdb
Alexis.
