[gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )

[gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )

[Michał Górny]

Hello,

As we've discussed multiple times, the following kind of dependencies
is completely broken and can't work:

  || ( media-libs/libav:= media-libs/ffmpeg:= )

For this reason, I would like to employ the solution used by Exherbo.
More specifically, use:

  libav? ( media-libs/libav:= )
  !libav? ( media-libs/ffmpeg:= )

This has two advantages:

1. gives users more explicit control over whether they want to use
libav or ffmpeg. Since the two have mutual blockers, right now random
packages could have tried to force you to switch from one to the other.
However, most often Portage would just give you terribly unreadable
blockers.

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.

The new USE flag descriptions would be:

  ffmpeg - Enable ffmpeg- or libav-based audio/video codec support
  libav - Prefer libav over ffmpeg

This implies that USE=ffmpeg is only present if ffmpeg/libav support is
optional while USE=libav is present to provide the choice between
ffmpeg and libav. While this isn't the most clear solution, it provides
backwards compatibility with the current use of USE=ffmpeg.

Any comments?

--
Best regards,
Michał Górny

Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )

[Matthias Maier]

> Any comments?

Sounds good!

Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )

[Rémi Cardona]

Why not :

libav? ( media-libs/libav:= )
ffmpeg? ( media-libs/ffmpeg:= )

+ REQUIRED_USE="^^ ( libav ffmpeg )"

I for one would never expect USE=-libav to enable ffmpeg (nor
USE=-ffmpeg to enable libav FWIW).

Rémi

Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 783 bytes --]

Dnia 2015-01-19, o godz. 23:09:55
Rémi Cardona <remi@gentoo.org> napisał(a):

> Why not :
> 
> libav? ( media-libs/libav:= )
> ffmpeg? ( media-libs/ffmpeg:= )
> 
> + REQUIRED_USE="^^ ( libav ffmpeg )"
> 
> I for one would never expect USE=-libav to enable ffmpeg (nor
> USE=-ffmpeg to enable libav FWIW).

Two reasons:

1. Compatibility. USE=ffmpeg is already used for || ( libav ffmpeg ) in
a lot of packages. If we changed the meaning, libav users will end up
switching '-ffmpeg libav' per-package. Ugly.

2. Feature-oriented flags. USE=ffmpeg represents the generic feature,
USE=libav is auxiliary implementation-switch flag. Well, maybe we could
use, say, USE=avcodec to avoid ambiguity but that's a larger change.


-- 
Best regards,
Michał Górny

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )

[Pacho Ramos]

El lun, 19-01-2015 a las 23:40 +0100, Michał Górny escribió:
> Dnia 2015-01-19, o godz. 23:09:55
> Rémi Cardona <remi@gentoo.org> napisał(a):
> 
> > Why not :
> > 
> > libav? ( media-libs/libav:= )
> > ffmpeg? ( media-libs/ffmpeg:= )
> > 
> > + REQUIRED_USE="^^ ( libav ffmpeg )"
> > 
> > I for one would never expect USE=-libav to enable ffmpeg (nor
> > USE=-ffmpeg to enable libav FWIW).
> 
> Two reasons:
> 
> 1. Compatibility. USE=ffmpeg is already used for || ( libav ffmpeg ) in
> a lot of packages. If we changed the meaning, libav users will end up
> switching '-ffmpeg libav' per-package. Ugly.
> 
> 2. Feature-oriented flags. USE=ffmpeg represents the generic feature,
> USE=libav is auxiliary implementation-switch flag. Well, maybe we could
> use, say, USE=avcodec to avoid ambiguity but that's a larger change.
> 
> 

I agree with your suggestion but I would prefer the Remi's approach of
letting people to know if they want "ffmpeg" or "libav", otherwise it is
not so obvious to know what disabling/enabling one of that USE flags
will end up causing without reading each ebuild :/ (also, maybe some
ebuilds will use one logic while others the inverse)

Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )

[Gordon Pettey]

[-- Attachment #1: Type: text/plain, Size: 1269 bytes --]

On Mon, Jan 19, 2015 at 4:40 PM, Michał Górny <mgorny@gentoo.org> wrote:

> Dnia 2015-01-19, o godz. 23:09:55
> Rémi Cardona <remi@gentoo.org> napisał(a):
>
> > Why not :
> >
> > libav? ( media-libs/libav:= )
> > ffmpeg? ( media-libs/ffmpeg:= )
> >
> > + REQUIRED_USE="^^ ( libav ffmpeg )"
> >
> > I for one would never expect USE=-libav to enable ffmpeg (nor
> > USE=-ffmpeg to enable libav FWIW).
>
> Two reasons:
>
> 1. Compatibility. USE=ffmpeg is already used for || ( libav ffmpeg ) in
> a lot of packages. If we changed the meaning, libav users will end up
> switching '-ffmpeg libav' per-package. Ugly.
>
>
There are only 61 packages with USE="ffmpeg", and quite few of those might
reasonably have package.use different from make.conf.


> 2. Feature-oriented flags. USE=ffmpeg represents the generic feature,
> USE=libav is auxiliary implementation-switch flag. Well, maybe we could
> use, say, USE=avcodec to avoid ambiguity but that's a larger change.


So, it is then expected to have both (USE="ffmpeg libav") to enable the
feature and then select the implementation? That's quite counter-intuitive,
and in some cases, there are some significant API differences - it is not
just a drop-in "auxiliary implementation".

[-- Attachment #2: Type: text/html, Size: 2048 bytes --]

Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )

[Michael Orlitzky]

On 01/19/2015 05:44 PM, Pacho Ramos wrote:
> 
> I agree with your suggestion but I would prefer the Remi's approach of
> letting people to know if they want "ffmpeg" or "libav", otherwise it is
> not so obvious to know what disabling/enabling one of that USE flags
> will end up causing without reading each ebuild :/ (also, maybe some
> ebuilds will use one logic while others the inverse)
> 

This triggered a repressed memory of a bug once filed against me:

https://blog.flameeyes.eu/2009/01/tinderboxing-problems-missing-default-use-flags

I vaguely agree, but please address any hate mail to Diego.

Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )

[Jason Zaman]

On Mon, Jan 19, 2015 at 08:31:45PM +0100, Michał Górny wrote:
> Hello,
> 
> As we've discussed multiple times, the following kind of dependencies
> is completely broken and can't work:
> 
>   || ( media-libs/libav:= media-libs/ffmpeg:= )
> 
> For this reason, I would like to employ the solution used by Exherbo.
> More specifically, use:
> 
>   libav? ( media-libs/libav:= )
>   !libav? ( media-libs/ffmpeg:= )

Is this going to be wrapped in a ffmpeg ? ( ) block?
What happens if I want libav and not ffmpeg and i set "-ffmpeg libav" in
make.conf? Does that mean I get nothing? cuz that is pretty
un-intuitive.

-- Jason

Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )

[Rémi Cardona]

Le 19/01/2015 23:40, Michał Górny a écrit :
> 1. Compatibility. USE=ffmpeg is already used for || ( libav ffmpeg ) in
> a lot of packages. If we changed the meaning, libav users will end up
> switching '-ffmpeg libav' per-package. Ugly.
> 
> 2. Feature-oriented flags. USE=ffmpeg represents the generic feature,
> USE=libav is auxiliary implementation-switch flag. Well, maybe we could
> use, say, USE=avcodec to avoid ambiguity but that's a larger change.

I think our users are clever enough to update their USE flags as they wish.

USE=ffmpeg for FFmpeg support + USE=libav for libav support is simple
and easily understood. I'd much rather we went with that.

Cheers,

Rémi

Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 980 bytes --]

Dnia 2015-01-20, o godz. 08:36:56
Rémi Cardona <remi@gentoo.org> napisał(a):

> Le 19/01/2015 23:40, Michał Górny a écrit :
> > 1. Compatibility. USE=ffmpeg is already used for || ( libav ffmpeg ) in
> > a lot of packages. If we changed the meaning, libav users will end up
> > switching '-ffmpeg libav' per-package. Ugly.
> > 
> > 2. Feature-oriented flags. USE=ffmpeg represents the generic feature,
> > USE=libav is auxiliary implementation-switch flag. Well, maybe we could
> > use, say, USE=avcodec to avoid ambiguity but that's a larger change.
> 
> I think our users are clever enough to update their USE flags as they wish.
> 
> USE=ffmpeg for FFmpeg support + USE=libav for libav support is simple
> and easily understood. I'd much rather we went with that.

It's not about cleverness. It's about Gentoo developers being clever
enough not to require users constantly going forth and back with
the USE flags.

-- 
Best regards,
Michał Górny

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )

[Alexis Ballier]

On Mon, 19 Jan 2015 20:31:45 +0100
Michał Górny <mgorny@gentoo.org> wrote:

> Hello,
> 
> As we've discussed multiple times, the following kind of dependencies
> is completely broken and can't work:
> 
>   || ( media-libs/libav:= media-libs/ffmpeg:= )

See end of the email.

> For this reason, I would like to employ the solution used by Exherbo.
> More specifically, use:
> 
>   libav? ( media-libs/libav:= )
>   !libav? ( media-libs/ffmpeg:= )
> 
> This has two advantages:
> 
> 1. gives users more explicit control over whether they want to use
> libav or ffmpeg. Since the two have mutual blockers, right now random
> packages could have tried to force you to switch from one to the
> other. However, most often Portage would just give you terribly
> unreadable blockers.


This sounds good to me; there are a few things to consider though:

- Whatever default useflag is enabled, people will have "terribly
  unreadable blockers" if they use the other implementation. It is even
  worse if you want to follow upstreams in their preferred
  implementation: some want libav, others ffmpeg...
- This is hidden by the proposal but it enforces that a package has
  equal visibility of both implementations (while the || requires only
  one); libav tends to have a faster code cleaning rate and thus a
  slower unmasking rate in gentoo. I agree with that requirement but
  this might end-up being unpractical since this means packages
  keywording and stabilization will have the slowest pace: mpv has been
  masked for 4 months and counting for this reason.
- What to do with packages like mplayer that haven't been building
  against libav for a year or so ?
- ffmpeg dep is media-video/ffmpeg:0= (not media-libs but more
  importantly the :0=)
- It is a good opportunity to kill virtual/ffmpeg and at the same time
  workaround a subslot and := deps limitation with virtuals.


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


Alexis.

Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )

[Zac Medico]

On 01/20/2015 12:13 AM, Alexis Ballier wrote:
> On Mon, 19 Jan 2015 20:31:45 +0100
> Michał Górny <mgorny@gentoo.org> wrote:
>> 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.

That's an interesting proposal, but I immediately find myself
questioning how closely it models reality. For example, maybe the
package links to both the a:= package and c:= package, or maybe just to
one of them. Shouldn't our model match reality as closely as possible,
as long as it's practical?
-- 
Thanks,
Zac

Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )

[Alexis Ballier]

On Tue, 20 Jan 2015 01:01:41 -0800
Zac Medico <zmedico@gentoo.org> wrote:

> On 01/20/2015 12:13 AM, Alexis Ballier wrote:
> > On Mon, 19 Jan 2015 20:31:45 +0100
> > Michał Górny <mgorny@gentoo.org> wrote:
> >> 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.
> 
> That's an interesting proposal, but I immediately find myself
> questioning how closely it models reality. For example, maybe the
> package links to both the a:= package and c:= package, or maybe just
> to one of them. Shouldn't our model match reality as closely as
> possible, as long as it's practical?

Do you have any such example ?

I think we can only make the safest assumption. Even without subslot,
if you consider this: || ( a b c d ), with a and c installed but
package automagically deciding to use only a, how can a PM decide
whether it is safe to remove a or not after the package has been
merged ?

Alexis.

Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )

[Luca Barbato]

On 20/01/15 03:07, Michael Orlitzky wrote:
> On 01/19/2015 05:44 PM, Pacho Ramos wrote:
>>
>> I agree with your suggestion but I would prefer the Remi's approach of
>> letting people to know if they want "ffmpeg" or "libav", otherwise it is
>> not so obvious to know what disabling/enabling one of that USE flags
>> will end up causing without reading each ebuild :/ (also, maybe some
>> ebuilds will use one logic while others the inverse)
>>
>
> This triggered a repressed memory of a bug once filed against me:
>
> https://blog.flameeyes.eu/2009/01/tinderboxing-problems-missing-default-use-flags
>
> I vaguely agree, but please address any hate mail to Diego.
>
>

Why?

Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )

[Michael Orlitzky]

On 01/20/2015 05:31 AM, Luca Barbato wrote:
>>
>> This triggered a repressed memory of a bug once filed against me:
>>
>> https://blog.flameeyes.eu/2009/01/tinderboxing-problems-missing-default-use-flags
>>
>> I vaguely agree, but please address any hate mail to Diego.
>>
>>
> 
> Why?
> 

It was a joke, but I thought it was funnier without the THIS IS A JOKE
end-of-line smiley face. Sorrrryyyy.

Seriously though: I think he's right, but I don't feel that strongly
about it.

Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 402 bytes --]

On Tue, 20 Jan 2015 09:13:19 +0100
Alexis Ballier <aballier@gentoo.org> wrote:
> More precisely: || ( a:= b c:= d ) is perfectly defined (in
> the "what it means" sense, not in PMS sense).

It really isn't... || ( a b c ) only "works" currently if a, b and c can
be switched at runtime. If you're using it for anything else, it only
works if you don't look too closely.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )

[Zac Medico]

On 01/20/2015 01:11 AM, Alexis Ballier wrote:
> On Tue, 20 Jan 2015 01:01:41 -0800
> Zac Medico <zmedico@gentoo.org> wrote:
> 
>> On 01/20/2015 12:13 AM, Alexis Ballier wrote:
>>> On Mon, 19 Jan 2015 20:31:45 +0100
>>> Michał Górny <mgorny@gentoo.org> wrote:
>>>> 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.
>>
>> That's an interesting proposal, but I immediately find myself
>> questioning how closely it models reality. For example, maybe the
>> package links to both the a:= package and c:= package, or maybe just
>> to one of them. Shouldn't our model match reality as closely as
>> possible, as long as it's practical?
> 
> Do you have any such example ?

Well, I think this demonstrates the sorts of ambiguities that may arise
when using || deps to model reality. We may find that replacing || deps
with USE conditionals and REQUIRED_USE constraints gives us a more
accurate and practical model for some kinds of dependencies.

> I think we can only make the safest assumption. Even without subslot,
> if you consider this: || ( a b c d ), with a and c installed but
> package automagically deciding to use only a, how can a PM decide
> whether it is safe to remove a or not after the package has been
> merged ?

Right, this demonstrates that || deps are ambiguous. So, maybe we should
look at alternatives that are not so ambiguous, such as USE conditionals
and REQUIRED_USE constraints.
-- 
Thanks,
Zac

Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )

[Alexis Ballier]

On Tue, 20 Jan 2015 09:28:21 -0800
Zac Medico <zmedico@gentoo.org> wrote:

> On 01/20/2015 01:11 AM, Alexis Ballier wrote:
> > On Tue, 20 Jan 2015 01:01:41 -0800
> > Zac Medico <zmedico@gentoo.org> wrote:
> > 
> >> On 01/20/2015 12:13 AM, Alexis Ballier wrote:
> >>> On Mon, 19 Jan 2015 20:31:45 +0100
> >>> Michał Górny <mgorny@gentoo.org> wrote:
> >>>> 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.
> >>
> >> That's an interesting proposal, but I immediately find myself
> >> questioning how closely it models reality. For example, maybe the
> >> package links to both the a:= package and c:= package, or maybe
> >> just to one of them. Shouldn't our model match reality as closely
> >> as possible, as long as it's practical?
> > 
> > Do you have any such example ?
> 
> Well, I think this demonstrates the sorts of ambiguities that may
> arise when using || deps to model reality. We may find that replacing
> || deps with USE conditionals and REQUIRED_USE constraints gives us a
> more accurate and practical model for some kinds of dependencies.

for the above example, yes of course, but this is because it is
another instance of automagic deps since you don't control to what the
package links to.

> > I think we can only make the safest assumption. Even without
> > subslot, if you consider this: || ( a b c d ), with a and c
> > installed but package automagically deciding to use only a, how can
> > a PM decide whether it is safe to remove a or not after the package
> > has been merged ?
> 
> Right, this demonstrates that || deps are ambiguous. So, maybe we
> should look at alternatives that are not so ambiguous, such as USE
> conditionals and REQUIRED_USE constraints.

if you assume there are no automagic deps, what is wrong and/or
ambiguous with '|| ( a b c d ) means "any of them, and at least all
that were available when the package was merged"' ?
in the above example this avoids PM breaking people systems by removing
'a' (e.g. if another packages pulls in 'd' that has a blocker against
'a') and as a side effect makes := deps work...

Alexis.

Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )

[Zac Medico]

On 01/20/2015 10:20 AM, Alexis Ballier wrote:
> On Tue, 20 Jan 2015 09:28:21 -0800
> Zac Medico <zmedico@gentoo.org> wrote:
> 
>> On 01/20/2015 01:11 AM, Alexis Ballier wrote:
>>> I think we can only make the safest assumption. Even without
>>> subslot, if you consider this: || ( a b c d ), with a and c
>>> installed but package automagically deciding to use only a, how can
>>> a PM decide whether it is safe to remove a or not after the package
>>> has been merged ?
>>
>> Right, this demonstrates that || deps are ambiguous. So, maybe we
>> should look at alternatives that are not so ambiguous, such as USE
>> conditionals and REQUIRED_USE constraints.
> 
> if you assume there are no automagic deps, what is wrong and/or
> ambiguous with '|| ( a b c d ) means "any of them, and at least all
> that were available when the package was merged"' ?
> in the above example this avoids PM breaking people systems by removing
> 'a' (e.g. if another packages pulls in 'd' that has a blocker against
> 'a') and as a side effect makes := deps work...

Sure, but when you start using words like "at least all that were
available when the package was merged", it shows a lack of precision in
your model. I tend to agree with Ciaran, that || deps are best suited to
dependencies that can be switched at runtime. For := deps, USE
conditionals and REQUIRED_USE constraints seem like a better fit.
-- 
Thanks,
Zac

Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )

[Michał Górny]

Dnia 2015-01-20, o godz. 09:13:19
Alexis Ballier <aballier@gentoo.org> napisał(a):

> > For this reason, I would like to employ the solution used by Exherbo.
> > More specifically, use:
> > 
> >   libav? ( media-libs/libav:= )
> >   !libav? ( media-libs/ffmpeg:= )
> > 
> > This has two advantages:
> > 
> > 1. gives users more explicit control over whether they want to use
> > libav or ffmpeg. Since the two have mutual blockers, right now random
> > packages could have tried to force you to switch from one to the
> > other. However, most often Portage would just give you terribly
> > unreadable blockers.
> 
> This sounds good to me; there are a few things to consider though:
> 
> - Whatever default useflag is enabled, people will have "terribly
>   unreadable blockers" if they use the other implementation. It is even
>   worse if you want to follow upstreams in their preferred
>   implementation: some want libav, others ffmpeg...

It's no better than it is now. I don't see any obvious solution, except
maybe for fake flags that would shout loudly at users, like USE=libav
with matching pkg_pretend() telling to change the global flag. As I see
it, this problem has no solution unless we're going to make the two
co-installable.

> - This is hidden by the proposal but it enforces that a package has
>   equal visibility of both implementations (while the || requires only
>   one); libav tends to have a faster code cleaning rate and thus a
>   slower unmasking rate in gentoo. I agree with that requirement but
>   this might end-up being unpractical since this means packages
>   keywording and stabilization will have the slowest pace: mpv has been
>   masked for 4 months and counting for this reason.

It will *at least* make those issues explicit and visible to repoman.
Rather than discovered via users hitting impossible dep trees.

> - What to do with packages like mplayer that haven't been building
>   against libav for a year or so ?

I don't know. pkg_pretend() like suggested above?

> - ffmpeg dep is media-video/ffmpeg:0= (not media-libs but more
>   importantly the :0=)

Those were just proof-of-concept examples, I didn't take care to write
them correctly ;P.

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

--
Best regards,
Michał Górny

Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )

[Alexis Ballier]

On Tue, 20 Jan 2015 22:43:52 +0100
Michał Górny <mgorny@gentoo.org> wrote:

> Dnia 2015-01-20, o godz. 09:13:19
> Alexis Ballier <aballier@gentoo.org> napisał(a):
> 
> > > For this reason, I would like to employ the solution used by
> > > Exherbo. More specifically, use:
> > > 
> > >   libav? ( media-libs/libav:= )
> > >   !libav? ( media-libs/ffmpeg:= )
> > > 
> > > This has two advantages:
> > > 
> > > 1. gives users more explicit control over whether they want to use
> > > libav or ffmpeg. Since the two have mutual blockers, right now
> > > random packages could have tried to force you to switch from one
> > > to the other. However, most often Portage would just give you
> > > terribly unreadable blockers.
> > 
> > This sounds good to me; there are a few things to consider though:
> > 
> > - Whatever default useflag is enabled, people will have "terribly
> >   unreadable blockers" if they use the other implementation. It is
> > even worse if you want to follow upstreams in their preferred
> >   implementation: some want libav, others ffmpeg...
> 
> It's no better than it is now. I don't see any obvious solution,
> except maybe for fake flags that would shout loudly at users, like
> USE=libav with matching pkg_pretend() telling to change the global
> flag. As I see it, this problem has no solution unless we're going to
> make the two co-installable.

There is indeed no solution I can think of but it is a bit worse than
what it is now at first: People that wanted to chose put their
implementation in world and were done. With this solution, such people
will have to adapt their useflags in make.conf. Don't get me wrong: I'm
all for changing it as you suggest (or remi suggests), I'm just saying
users might have a hard time finding out what those portage blockers
mean and how to fix it. In the long term your proposal is a better
solution but the first time will be painful IMHO.


> > - This is hidden by the proposal but it enforces that a package has
> >   equal visibility of both implementations (while the || requires
> > only one); libav tends to have a faster code cleaning rate and thus
> > a slower unmasking rate in gentoo. I agree with that requirement but
> >   this might end-up being unpractical since this means packages
> >   keywording and stabilization will have the slowest pace: mpv has
> > been masked for 4 months and counting for this reason.
> 
> It will *at least* make those issues explicit and visible to repoman.
> Rather than discovered via users hitting impossible dep trees.

They're usually not impossible, but my point was rather: Is this
something everyone wants ?


> > - What to do with packages like mplayer that haven't been building
> >   against libav for a year or so ?
> 
> I don't know. pkg_pretend() like suggested above?

Me neither. pkg_pretend will be too intrusive into packages I think
(and there are quite a few). I remember something that enabled useflags
based on if you had a given package installed.
/me runs

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

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:= )'...

Alexis.

Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2895 bytes --]

Dnia 2015-01-21, o godz. 11:05:01
Alexis Ballier <aballier@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:

1. What does || ( a b:= c:= ) mean? i.e. only some having subslots.

2. What does || ( a:= b:= ) mean when a and b can be both installed?

Adding a very specific PMS rule for two packages doesn't sound like
a very good idea to me.

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

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 )

-- 
Best regards,
Michał Górny

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )

[Alexis Ballier]

On Tue, 20 Jan 2015 10:33:49 -0800
Zac Medico <zmedico@gentoo.org> wrote:

> On 01/20/2015 10:20 AM, Alexis Ballier wrote:
> > On Tue, 20 Jan 2015 09:28:21 -0800
> > Zac Medico <zmedico@gentoo.org> wrote:
> > 
> >> On 01/20/2015 01:11 AM, Alexis Ballier wrote:
> >>> I think we can only make the safest assumption. Even without
> >>> subslot, if you consider this: || ( a b c d ), with a and c
> >>> installed but package automagically deciding to use only a, how
> >>> can a PM decide whether it is safe to remove a or not after the
> >>> package has been merged ?
> >>
> >> Right, this demonstrates that || deps are ambiguous. So, maybe we
> >> should look at alternatives that are not so ambiguous, such as USE
> >> conditionals and REQUIRED_USE constraints.
> > 
> > if you assume there are no automagic deps, what is wrong and/or
> > ambiguous with '|| ( a b c d ) means "any of them, and at least all
> > that were available when the package was merged"' ?
> > in the above example this avoids PM breaking people systems by
> > removing 'a' (e.g. if another packages pulls in 'd' that has a
> > blocker against 'a') and as a side effect makes := deps work...
> 
> Sure, but when you start using words like "at least all that were
> available when the package was merged", it shows a lack of precision
> in your model.

"all that were available when the package was merged" is perfectly
defined. The "at least" is to allow room for dynamic deps but can be
dropped.
Simple words don't make things less precise, just more readable :)

[...]

Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )

[Alexis Ballier]

On Wed, 21 Jan 2015 11:15:04 +0100
Michał Górny <mgorny@gentoo.org> wrote:

> Dnia 2015-01-21, o godz. 11:05:01
> Alexis Ballier <aballier@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.

Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 5259 bytes --]

Dnia 2015-01-21, o godz. 12:12:21
Alexis Ballier <aballier@gentoo.org> napisał(a):

> On Wed, 21 Jan 2015 11:15:04 +0100
> Michał Górny <mgorny@gentoo.org> wrote:
> 
> > Dnia 2015-01-21, o godz. 11:05:01
> > Alexis Ballier <aballier@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.

I'm just describing the current Portage behavior. By 'effective deps' I
mean 'what Portage puts in depgraph' when it sees || ( a:= b:= ).

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

A fair bit inconsistent but I guess it is the safe solution. Of course,
it is ugly for making || () behave completely different from
the original meaning when := is used inside. You add subslot, you get
completely different behavior. You remove it, you get completely
different behavior...

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

It is easy to write others how to do stuff without looking at the code,
isn't it?

-- 
Best regards,
Michał Górny

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )

[Alexis Ballier]

On Wed, 21 Jan 2015 19:21:28 +0100
Michał Górny <mgorny@gentoo.org> wrote:

[...]
> > > 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.
> 
> A fair bit inconsistent but I guess it is the safe solution. Of
> course, it is ugly for making || () behave completely different from
> the original meaning when := is used inside. You add subslot, you get
> completely different behavior. You remove it, you get completely
> different behavior...

Can you answer the same question removing ':=' ?
I might have missed something but, as I see it, it is the same meaning
with and without :=, and this just provides an algorithm on how to
trigger the rebuilds.

[...]
> It is easy to write others how to do stuff without looking at the
> code, isn't it?

It is, indeed. But two things:

1. If portage uses crafted depstrings in its depgraph when rebuilding a
package and nobody is able to give me a good reason _why_ this is
needed, I really do not want to look at the code :)

2. From my experience, such input is very useful: Yes, it often annoys
me and sometimes even pisses me off that some external guy comes and
tells me I have to trash all that code I wrote, that costed me a lot,
and even I have problems understanding it. But, in the end, more often
than not, I realize that I was too much into the code and not enough
into understanding and simplifying the global picture and that
this external input allows me to make the code simpler, less buggy and
much more maintainable.

Alexis.

Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )

[Zac Medico]

On 01/21/2015 11:25 PM, Alexis Ballier wrote:
> 1. If portage uses crafted depstrings in its depgraph when rebuilding a
> package and nobody is able to give me a good reason _why_ this is
> needed, I really do not want to look at the code :)

It's the emerge --dynamic-deps option, which is enabled by default. If
you want to use --dynamic-deps=n, then you may need to fix some
dependencies of installed packages, which you can do by running emerge
@changed-deps. There's also a --changed-deps [1] option that can be
applied to @world updates, which will be included in Portage 2.2.16.

[1]
https://github.com/gentoo/portage/commit/e99fa094ac73514b23509a0f8305b365f114e9a3
-- 
Thanks,
Zac

Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )

[Alexis Ballier]

On Thu, 22 Jan 2015 02:50:44 -0800
Zac Medico <zmedico@gentoo.org> wrote:

> On 01/21/2015 11:25 PM, Alexis Ballier wrote:
> > 1. If portage uses crafted depstrings in its depgraph when
> > rebuilding a package and nobody is able to give me a good reason
> > _why_ this is needed, I really do not want to look at the code :)
> 
> It's the emerge --dynamic-deps option, which is enabled by default. If
> you want to use --dynamic-deps=n, then you may need to fix some
> dependencies of installed packages, which you can do by running emerge
> @changed-deps. There's also a --changed-deps [1] option that can be
> applied to @world updates, which will be included in Portage 2.2.16.
> 
> [1]
> https://github.com/gentoo/portage/commit/e99fa094ac73514b23509a0f8305b365f114e9a3

This answers 'how' and, as I understand it, changed-deps is also about
'how' to trigger rebuild.
My question was: _why_ when portage knows what package to rebuild
doesn't it use the dep string from the ebuild ?

That's what I understand from Michał's comment (quoting him):

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


As I understand it, portage (correctly) marks this package for rebuild
(because ffmpeg:0/51= dep isn't satisfied anymore), but I don't get why
it doesn't consider the original '|| ( ffmpeg:= libav:= )' dep for the
depgraph and wants to pull ffmpeg in "because of :=".

Alexis.

Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )

[Zac Medico]

On 01/22/2015 03:11 AM, Alexis Ballier wrote:
> On Thu, 22 Jan 2015 02:50:44 -0800
> Zac Medico <zmedico@gentoo.org> wrote:
> 
>> On 01/21/2015 11:25 PM, Alexis Ballier wrote:
>>> 1. If portage uses crafted depstrings in its depgraph when
>>> rebuilding a package and nobody is able to give me a good reason
>>> _why_ this is needed, I really do not want to look at the code :)
>>
>> It's the emerge --dynamic-deps option, which is enabled by default. If
>> you want to use --dynamic-deps=n, then you may need to fix some
>> dependencies of installed packages, which you can do by running emerge
>> @changed-deps. There's also a --changed-deps [1] option that can be
>> applied to @world updates, which will be included in Portage 2.2.16.
>>
>> [1]
>> https://github.com/gentoo/portage/commit/e99fa094ac73514b23509a0f8305b365f114e9a3
> 
> This answers 'how' and, as I understand it, changed-deps is also about
> 'how' to trigger rebuild.
> My question was: _why_ when portage knows what package to rebuild
> doesn't it use the dep string from the ebuild ?

It does use the dep string for the ebuild, after it has rejected the
installed instance and decided to pull in the ebuild instead.

> That's what I understand from Michał's comment (quoting him):
> 
>> 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=
> 
> 
> As I understand it, portage (correctly) marks this package for rebuild
> (because ffmpeg:0/51= dep isn't satisfied anymore), but I don't get why
> it doesn't consider the original '|| ( ffmpeg:= libav:= )' dep for the
> depgraph and wants to pull ffmpeg in "because of :=".

It does consider the original dep. However, it also uses various
heuristics when making choices for || deps, and the fact that an
instance of ffmpeg is currently installed is taken into account in the
heuristics.
-- 
Thanks,
Zac

Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )

[Alexis Ballier]

On Thu, 22 Jan 2015 09:06:39 -0800
Zac Medico <zmedico@gentoo.org> wrote:

[...]
> > That's what I understand from Michał's comment (quoting him):
> > 
> >> 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=
> > 
> > 
> > As I understand it, portage (correctly) marks this package for
> > rebuild (because ffmpeg:0/51= dep isn't satisfied anymore), but I
> > don't get why it doesn't consider the original '|| ( ffmpeg:=
> > libav:= )' dep for the depgraph and wants to pull ffmpeg in
> > "because of :=".
> 
> It does consider the original dep. However, it also uses various
> heuristics when making choices for || deps, and the fact that an
> instance of ffmpeg is currently installed is taken into account in the
> heuristics.

good then; i'm assuming: people have ffmpeg installed and built a
package 'foo' with || ( ffmpeg:= libav:= ); now, he removes ffmpeg,
installs libav (put it in world), and masks ffmpeg (shouldnt be needed
since it blocks libav but may hint portage solver).

what Michał claims is that 'foo' will want ffmpeg, no matter what. how
can it be possible if 'foo' is slatted for rebuild ? or maybe it is
that portage does not slat it for rebuild (dynamic deps or not) ? how
can it force to install ffmpeg then ?

Alexis.

Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )

[Zac Medico]

On 01/23/2015 01:48 AM, Alexis Ballier wrote:
> On Thu, 22 Jan 2015 09:06:39 -0800
> Zac Medico <zmedico@gentoo.org> wrote:
> 
> [...]
>>> That's what I understand from Michał's comment (quoting him):
>>>
>>>> 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=
>>>
>>>
>>> As I understand it, portage (correctly) marks this package for
>>> rebuild (because ffmpeg:0/51= dep isn't satisfied anymore), but I
>>> don't get why it doesn't consider the original '|| ( ffmpeg:=
>>> libav:= )' dep for the depgraph and wants to pull ffmpeg in
>>> "because of :=".
>>
>> It does consider the original dep. However, it also uses various
>> heuristics when making choices for || deps, and the fact that an
>> instance of ffmpeg is currently installed is taken into account in the
>> heuristics.
> 
> good then; i'm assuming: people have ffmpeg installed and built a
> package 'foo' with || ( ffmpeg:= libav:= ); now, he removes ffmpeg,
> installs libav (put it in world), and masks ffmpeg (shouldnt be needed
> since it blocks libav but may hint portage solver).

Yes, putting ffmpeg in package.mask is not strictly necessary, but it
may help you avoid having portage try to pull in ffmpeg to satisfy a
dependency at some point.

> what Michał claims is that 'foo' will want ffmpeg, no matter what.

Maybe he's talking about some case where portage failed to trigger a
rebuild when appropriate. We've had a number of bugs like this that have
been fixed. The most recent recent example is bug 531656 [1].

> how can it be possible if 'foo' is slatted for rebuild ?

It's not possible, as long as a rebuild has be properly triggered.

> or maybe it is
> that portage does not slat it for rebuild (dynamic deps or not) ?

Yeah, we may find more bugs similar to bug 531656. When we discover bugs
like this, I make them block bug 300071 [2].

> how can it force to install ffmpeg then ?

It will only happen if portage fails to trigger a rebuild. If you have a
problem like this, then I would recommend to try all of the following
(starting with the least invasive):

1) emerge --deselect media-video/ffmpeg (remove from world file)
2) echo media-video/ffmpeg >> /etc/portage/package.mask (mask ffmpeg)
3) emerge --unmerge media-video/ffmpeg

[1] https://bugs.gentoo.org/show_bug.cgi?id=531656
[2] https://bugs.gentoo.org/show_bug.cgi?id=300071
-- 
Thanks,
Zac

Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )

[Alexis Ballier]

On Fri, 23 Jan 2015 09:19:19 -0800
Zac Medico <zmedico@gentoo.org> wrote:

> > what Michał claims is that 'foo' will want ffmpeg, no matter what.
> 
> Maybe he's talking about some case where portage failed to trigger a
> rebuild when appropriate. We've had a number of bugs like this that
> have been fixed. The most recent recent example is bug 531656 [1].

Yes I know about this one :) To be honest I find it much more
difficult and convoluted (?) than the present case, yet you fixed it.
Even worse: there has been tree-wide changes made because of this
(removal of := from all || ( ffmpeg:= libav:= )) instead of filling
portage bugs... which I consider just plain wrong and was in fact my
initial rant.

Alexis.

Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 985 bytes --]

Dnia 2015-01-26, o godz. 12:57:36
Alexis Ballier <aballier@gentoo.org> napisał(a):

> On Fri, 23 Jan 2015 09:19:19 -0800
> Zac Medico <zmedico@gentoo.org> wrote:
> 
> > > what Michał claims is that 'foo' will want ffmpeg, no matter what.
> > 
> > Maybe he's talking about some case where portage failed to trigger a
> > rebuild when appropriate. We've had a number of bugs like this that
> > have been fixed. The most recent recent example is bug 531656 [1].
> 
> Yes I know about this one :) To be honest I find it much more
> difficult and convoluted (?) than the present case, yet you fixed it.
> Even worse: there has been tree-wide changes made because of this
> (removal of := from all || ( ffmpeg:= libav:= )) instead of filling
> portage bugs... which I consider just plain wrong and was in fact my
> initial rant.

This was done after contacting the PMS team, and I think Portage team
as well but not sure anymore.

-- 
Best regards,
Michał Górny

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )

[Zac Medico]

On 01/26/2015 03:57 AM, Alexis Ballier wrote:
> On Fri, 23 Jan 2015 09:19:19 -0800
> Zac Medico <zmedico@gentoo.org> wrote:
> 
>>> what Michał claims is that 'foo' will want ffmpeg, no matter what.
>>
>> Maybe he's talking about some case where portage failed to trigger a
>> rebuild when appropriate. We've had a number of bugs like this that
>> have been fixed. The most recent recent example is bug 531656 [1].
> 
> Yes I know about this one :) To be honest I find it much more
> difficult and convoluted (?) than the present case, yet you fixed it.

I like to handle as many cases as practically possible, because the same
heuristics may be applicable to many other cases that haven't been
reported yet.

> Even worse: there has been tree-wide changes made because of this
> (removal of := from all || ( ffmpeg:= libav:= )) instead of filling
> portage bugs... which I consider just plain wrong and was in fact my
> initial rant.

Well, the ability of portage to handle a particular type of dependency
construct does not necessarily imply that this type of dependency
construct should be encouraged.
-- 
Thanks,
Zac