Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )
Dnia 2015-01-26, o godz. 12:57:36 Alexis Ballier aball...@gentoo.org napisał(a): On Fri, 23 Jan 2015 09:19:19 -0800 Zac Medico zmed...@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 pgpNLv2mwC0tX.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )
On 01/26/2015 03:57 AM, Alexis Ballier wrote: On Fri, 23 Jan 2015 09:19:19 -0800 Zac Medico zmed...@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
Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )
On Fri, 23 Jan 2015 09:19:19 -0800 Zac Medico zmed...@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:= )
On 01/23/2015 01:48 AM, Alexis Ballier wrote: On Thu, 22 Jan 2015 09:06:39 -0800 Zac Medico zmed...@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:= )
On Thu, 22 Jan 2015 09:06:39 -0800 Zac Medico zmed...@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:= )
On Thu, 22 Jan 2015 02:50:44 -0800 Zac Medico zmed...@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:= )
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:= )
On 01/22/2015 03:11 AM, Alexis Ballier wrote: On Thu, 22 Jan 2015 02:50:44 -0800 Zac Medico zmed...@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:= )
Dnia 2015-01-21, o godz. 12:12:21 Alexis Ballier aball...@gentoo.org napisał(a): 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. 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 pgp7seKLVuJap.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )
On Wed, 21 Jan 2015 19:21:28 +0100 Michał Górny mgo...@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:= )
On Tue, 20 Jan 2015 22:43:52 +0100 Michał Górny mgo...@gentoo.org wrote: Dnia 2015-01-20, o godz. 09:13:19 Alexis Ballier aball...@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:= )
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.
Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )
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: 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 pgpXyKkWYNzeN.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )
On Tue, 20 Jan 2015 10:33:49 -0800 Zac Medico zmed...@gentoo.org wrote: On 01/20/2015 10:20 AM, Alexis Ballier wrote: On Tue, 20 Jan 2015 09:28:21 -0800 Zac Medico zmed...@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:= )
On Mon, 19 Jan 2015 20:31:45 +0100 Michał Górny mgo...@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:= )
On Tue, 20 Jan 2015 01:01:41 -0800 Zac Medico zmed...@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 mgo...@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:= )
On 01/20/2015 12:13 AM, Alexis Ballier wrote: On Mon, 19 Jan 2015 20:31:45 +0100 Michał Górny mgo...@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:= )
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:= )
On Tue, 20 Jan 2015 09:13:19 +0100 Alexis Ballier aball...@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 signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )
On 01/20/2015 01:11 AM, Alexis Ballier wrote: On Tue, 20 Jan 2015 01:01:41 -0800 Zac Medico zmed...@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 mgo...@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:= )
On Tue, 20 Jan 2015 09:28:21 -0800 Zac Medico zmed...@gentoo.org wrote: On 01/20/2015 01:11 AM, Alexis Ballier wrote: On Tue, 20 Jan 2015 01:01:41 -0800 Zac Medico zmed...@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 mgo...@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:= )
On 01/20/2015 10:20 AM, Alexis Ballier wrote: On Tue, 20 Jan 2015 09:28:21 -0800 Zac Medico zmed...@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:= )
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. So. 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:= )
Dnia 2015-01-20, o godz. 09:13:19 Alexis Ballier aball...@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:= )
Dnia 2015-01-19, o godz. 23:09:55 Rémi Cardona r...@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 pgp9UBc_kkA0a.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )
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:= )
On Mon, Jan 19, 2015 at 4:40 PM, Michał Górny mgo...@gentoo.org wrote: Dnia 2015-01-19, o godz. 23:09:55 Rémi Cardona r...@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.
Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )
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 r...@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:= )
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:= )
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:= )
Dnia 2015-01-20, o godz. 08:36:56 Rémi Cardona r...@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 pgpbzQAD0iWQH.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )
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:= )
Any comments? Sounds good!
