Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/03/2015 02:04 PM, Michał Górny wrote: Dnia 2015-02-02, o godz. 15:06:40 Michał Górny mgo...@gentoo.org napisał(a): Hi, everyone. Just after the news item got published, user Wes mailed me with a suggestion. While I think someone mentioned it earlier in the bikesheds over ffmpeg, I have completely forgotten about it and now I'd like to reconsider it. For this reason, I've reverted the news item while it's still fresh and p.masked the revbumps. The idea is that instead of having USE=libav (that's tangential to USE=ffmpeg and confusing) to use a USE_EXPAND like FFMPEG_IMPL taking either ffmpeg or libav. Now, why... Oh, in case we go this way as the forums poll suggests [1], I'm attaching the updated news item for review. [1]:http://forums.gentoo.org/viewtopic-t-1009988.html I think this is getting too complicated in the sense that we bloat the make.conf file with new variables every now and then for no good reason. As a result, the time spent to maintain make.conf has been increased over time leading to more headaches on world updates etc. make.conf is there for a good reason, and that is to help you make your system highly configurable, but this should not get too complicated otherwise people will just lose interest and use a good-default one instead of spending half an hour tweaking it. imho, in this particular case, the old behavior is fine by me and it's what has been around for a long time. If that's not clear, or causes confusing, perhaps it would be best to document the use flags in a better way and deal with it. - -- Regards, Markos Chandras -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQF8BAEBCgBmBQJU0UaIXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8ZNlQIAI0ZmTxUkNj2Food8yoH7pO8 jT1kJEPObHDdnjegLzkytISqBLHsGK12fsyKQlQTrwn3cEtiCnZV/PFgP/Afz3o4 iapGa6zKSSLJA3wyQhHuSw8rnqxyV22H2sh5aqmnbxnh6ENamQ1XSVjLgsLq3/K7 gjG5MQG09KEKpjvZPCpHs0CvznfWJAuRa3mprHGiTdtOm8ooztTH76er/KWjndOV pyFneHABL7devZuJvPqSwz+mqJ5SDcc72P4tdGRhw1fF/v0cnrlL6pnYiOmlGREy TNJB7udrZnp/poZkArCC0eiIWBXRKirdM8NfozF/jVgUjOb+A9sb9fquSFO8z2E= =U+v7 -END PGP SIGNATURE-
Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
Dnia 2015-02-02, o godz. 15:06:40 Michał Górny mgo...@gentoo.org napisał(a): Hi, everyone. Just after the news item got published, user Wes mailed me with a suggestion. While I think someone mentioned it earlier in the bikesheds over ffmpeg, I have completely forgotten about it and now I'd like to reconsider it. For this reason, I've reverted the news item while it's still fresh and p.masked the revbumps. The idea is that instead of having USE=libav (that's tangential to USE=ffmpeg and confusing) to use a USE_EXPAND like FFMPEG_IMPL taking either ffmpeg or libav. Now, why... Oh, in case we go this way as the forums poll suggests [1], I'm attaching the updated news item for review. [1]:http://forums.gentoo.org/viewtopic-t-1009988.html -- Best regards, Michał Górny Title: ffmpeg/libav conflict management: USE=libav Author: MichaÅ Górny mgo...@gentoo.org Content-Type: text/plain Posted: 2015-02-01 Revision: 2 News-Item-Format: 1.0 Display-If-Installed: media-video/ffmpeg Display-If-Installed: media-video/libav The support for automatic choice between ffmpeg and libav is going to be deprecated in favor of explicit choice via USE flags. This change aims to solve multiple repeating issues, including Portage undesirably wanting to replace one package with the other, lack of proper reverse dependency on ffmpeg/libav upgrades and some of the hard-to-understand upgrade failures involving blockers. It also may be used to make ffmpeg and libav co-installable in the future. The current USE=ffmpeg will maintain its role of enabling optional support for ffmpeg or a replacement implementation (libav) in a package. However, whenever appropriate additional FFMPEG_IMPL flags will be introduced to control the preference of one implementation over the other(s). Users who currently use libav (the Gentoo default) do not have to perform any action since FFMPEG_IMPL=libav is set by default. Users who prefer ffmpeg instead need to specify FFMPEG_IMPL=ffmpeg in make.conf. It should be noted that the FFMPEG_IMPL flags are descendants of USE=ffmpeg, and therefore USE=ffmpeg still needs to be enabled whenever a package has optional ffmpeg/libav support. Please also note that some packages support only one of the two implementations. An attempt to install one of those packages may result in blockers requiring the user changes the value of FFMPEG_IMPL. The most notable example of such package is media-video/mplayer. media-video/mpv may be used as a replacement for users who prefer libav. Please do not alter the state of FFMPEG_IMPL on a per-package basis (e.g. via package.use). The flags need to be set globally to have consistent value throughout all packages. Otherwise, blockers will occur and prevent upgrades. pgp4tyAUhaIna.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
Dnia 2015-02-02, o godz. 15:06:40
Michał Górny mgo...@gentoo.org napisał(a):
The idea is that instead of having USE=libav (that's tangential to
USE=ffmpeg and confusing) to use a USE_EXPAND like FFMPEG_IMPL taking
either ffmpeg or libav. Now, why...
Ok, since this is going to be a long night, a quick summary of
the alternatives.
First of all, plain USE='ffmpeg libav' where each one signifies one of
the impls. This can't work because we already have packages that depend
on, say, 'app-misc/tracker[ffmpeg]'. If we replaced that with two
optional flags, we'd have to do '|| ( tracker[ffmpeg] tracker[libav]
)'. And || () deps are pretty much fragile, don't support := operator
and cause unpredictable blockers during dependency resolution. So this
can't work.
Secondly, global variables that are not USE flags. They can't work
since the dependencies in ebuilds need to be consistent and can not be
affected by external variables.
Thirdly, || () blocks. I already listed above why they must not be used.
So, after throwing all technically unsound solutions, we are left with
having to have exactly one *feature flag* -- the flag that enables
ffmpeg-or-libav support in the packages that have it optional, and one
or more *implementation flags* that select the implementation when more
than one can be used.
For feature flag, name is the only issue. Currently USE=ffmpeg serves
that purpose and I think changing that would have a very high cost
(and cause a lot of bikeshed), esp. if we would end up reusing the flag
for another purpose. So most likely leave it as-is.
For implementation flags, we have three options:
a. one binary 'libav' flag that switches between the two
implementations,
b. two regular unary flags that select one of the implementations,
c. two USE_EXPAND unary flags that select one of the implementations.
A. binary 'libav' flag (or similar)
default set in profiles:
USE=${USE} libav
user changes impl to ffmpeg:
USE=-libav
portage output:
media-video/foo USE=... ffmpeg ... libav ...
ebuild code:
IUSE=ffmpeg libav
RDEPEND=
ffmpeg? (
!libav? ( media-video/ffmpeg:0= )
libav? ( media-video/libav:0= )
)
non-meaningful flag combinations:
USE=-ffmpeg libav - doesn't give you libav
B. two regular unary flags (i'm going to use ffmpeg/libav here but
the names would likely have to be different)
default set in profiles:
USE=${USE} libav
user changes impl to ffmpeg:
USE=-libav ffmpeg
portage output:
media-video/foo USE=... avcodec ... libav ... -ffmpeg ...
ebuild code:
IUSE=avcodec ffmpeg libav
RDEPEND=
avcodec? (
ffmpeg? ( media-video/ffmpeg:0= )
libav? ( media-video/libav:0= )
)
REQUIRED_USE=avcodec? ( ^^ ( ffmpeg libav ) )
non-meaningful flag combinations:
USE=-avcodec * - doesn't give you libav or ffmpeg
disallowed flag combinations:
USE=avcodec -ffmpeg -libav - no implementation selected
USE=avcodec ffmpeg libav - multiple implementations selected
C. two USE_EXPAND unary flags
default set in profiles:
FFMPEG_IMPL=libav
user changes impl to ffmpeg:
FFMPEG_IMPL=ffmpeg
portage output:
media-video/foo USE=... ffmpeg ... FFMPEG_IMPL=libav -ffmpeg
ebuild code (yeah, pain to type -- but only once...):
IUSE=ffmpeg ffmpeg_impl_ffmpeg ffmpeg_impl_libav
RDEPEND=
ffmpeg? (
ffmpeg_impl_ffmpeg? ( media-video/ffmpeg:0= )
ffmpeg_impl_libav? ( media-video/libav:0= )
)
REQUIRED_USE=ffmpeg? ( ^^ ( ffmpeg_impl_ffmpeg ffmpeg_impl_libav ) )
non-meaningful flag combinations:
USE=-ffmpeg FFMPEG_IMPL=* - doesn't give you libav or ffmpeg
disallowed flag combinations:
USE=ffmpeg FFMPEG_IMPL=-ffmpeg -libav - no implementation selected
USE=ffmpeg FFMPEG_IMPL=ffmpeg libav - multiple implementations selected
--
Best regards,
Michał Górny
pgpFc6utuRKj0.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
On 02/02/2015 05:47 PM, Michał Górny wrote: For feature flag, name is the only issue. Currently USE=ffmpeg serves that purpose and I think changing that would have a very high cost (and cause a lot of bikeshed), esp. if we would end up reusing the flag for another purpose. So most likely leave it as-is. Agreed. For implementation flags, we have three options: a. one binary 'libav' flag that switches between the two implementations, This is what I was trying to convey earlier. non-meaningful flag combinations: USE=-ffmpeg libav - doesn't give you libav Except I wouldn't name the implementation flag libav because that's confusing. Name it ffmpeg-impl-libav or whatever's allowed by the PMS. Then, USE=-ffmpeg ffmpeg-impl-libav - doesn't give you libav is not weird.
Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
On Mon, 2 Feb 2015, Michał Górny wrote: FFMPEG_IMPL feels like a natural extension of USE=ffmpeg. USE=ffmpeg tells to use ffmpeg or a replacement, FFMPEG_IMPL tells what will exactly get used. Much less confusion. Thirdly, this opens space for having more than two different implementations in the future without having to reset the system. Maybe this isn't something worth considering but -- as I see it -- the first big fork starts a precedent, and both current versions suck :). Fourthly, there's the case of implicity. Right now USE=-libav implies ffmpeg. Therefore, USE=-* implies ffmpeg as well -- which is kinda weird since it's supposedly the non-default. With this solution, USE=-* will result in explicit error asking user to select an implementation. As for the downsides: 1. there is a number of non-meaningful flag combinations. FFMPEG_IMPL='', FFMPEG_IMPL='ffmpeg libav'. They will have to be blocked via REQUIRED_USE='^^ ( ffmpeg_impl_ffmpeg ffmpeg_impl_libav )'. 2. There is some more work to get ebuilds correct (REQUIRED_USE). However, this is a minor issue compared to the potential mistakes in interpretation of USE='ffmpeg' and USE='libav'. What are your thoughts? In a nutshell, you have a binary choice here, namely ffmpeg or libav as implementation, and instead of one USE flag you want to introduce two (ffmpeg_impl_ffmpeg and ffmpeg_impl_libav), but of the 4 possible combinations only 2 are valid. So you need a REQUIRED_USE to forbid some combinations. Please spare us of this. Ulrich pgpIkVFI7ycMJ.pgp Description: PGP signature
Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
On 02/02/2015 09:12 AM, Ulrich Mueller wrote: What are your thoughts? In a nutshell, you have a binary choice here, namely ffmpeg or libav as implementation, and instead of one USE flag you want to introduce two (ffmpeg_impl_ffmpeg and ffmpeg_impl_libav), but of the 4 possible combinations only 2 are valid. So you need a REQUIRED_USE to forbid some combinations. Please spare us of this. Why do we need two flags for this? Wouldn't a single global USE=ffmpeg_impl_libav have exactly the desired behavior?
Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
Dnia 2015-02-02, o godz. 10:44:46 Michael Orlitzky m...@gentoo.org napisał(a): On 02/02/2015 09:12 AM, Ulrich Mueller wrote: What are your thoughts? In a nutshell, you have a binary choice here, namely ffmpeg or libav as implementation, and instead of one USE flag you want to introduce two (ffmpeg_impl_ffmpeg and ffmpeg_impl_libav), but of the 4 possible combinations only 2 are valid. So you need a REQUIRED_USE to forbid some combinations. Please spare us of this. Why do we need two flags for this? Wouldn't a single global USE=ffmpeg_impl_libav have exactly the desired behavior? Maybe. Though it still will keep the confusion of !libav meaning ffmpeg. I mean: ffmpeg? ( !libav? ( ffmpeg ) libav? ( ffmpeg ) ) (or without the outer 'ffmpeg?'). In your variant: ffmpeg? ( !ffmpeg_impl_libav? ( ffmpeg ) ffmpeg_impl_libav? ( ffmpeg ) ) Maybe a little cleaner but still relies on the implicit thing. Not to mention the user is supposed to set either: FFMPEG_IMPL=libav or: FFMPEG_IMPL= which is nowhere close to sane :). -- Best regards, Michał Górny pgps1Uqc3SzWL.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
Dnia 2015-02-02, o godz. 08:54:04 Gordon Pettey petteyg...@gmail.com napisał(a): Having USE=ffmpeg at all is the source of any confusion in case somebody is using libav. Either with an expand set (which seems wasted just for two options) or two regular flags, just force one or none. There is absolutely no sense in having USE=ffmpeg on for a system using libav. If things were that simple, you wouldn't need me :P. This would mean that the flags have two slightly different uses. They either enable ffmpeg or libav when it is optional, or they choose between ffmpeg or libav when it is not. Not that bad? Now if we want to default to libav, we set USE=libav. Oh wait, that enables optional libav support in all packages. And if we don't do that, a number of packages with obligatory ffmpeg/libav support doesn't install by default. Users have real trouble setting their preferences too. If they prefer ffmpeg, they need to change that for every package in question or they implicitly enable the optional support for all packages. -- Best regards, Michał Górny pgp2s0QAAxlmT.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
Having USE=ffmpeg at all is the source of any confusion in case somebody is using libav. Either with an expand set (which seems wasted just for two options) or two regular flags, just force one or none. There is absolutely no sense in having USE=ffmpeg on for a system using libav. On Mon, Feb 2, 2015 at 8:12 AM, Ulrich Mueller u...@gentoo.org wrote: On Mon, 2 Feb 2015, Michał Górny wrote: FFMPEG_IMPL feels like a natural extension of USE=ffmpeg. USE=ffmpeg tells to use ffmpeg or a replacement, FFMPEG_IMPL tells what will exactly get used. Much less confusion. Thirdly, this opens space for having more than two different implementations in the future without having to reset the system. Maybe this isn't something worth considering but -- as I see it -- the first big fork starts a precedent, and both current versions suck :). Fourthly, there's the case of implicity. Right now USE=-libav implies ffmpeg. Therefore, USE=-* implies ffmpeg as well -- which is kinda weird since it's supposedly the non-default. With this solution, USE=-* will result in explicit error asking user to select an implementation. As for the downsides: 1. there is a number of non-meaningful flag combinations. FFMPEG_IMPL='', FFMPEG_IMPL='ffmpeg libav'. They will have to be blocked via REQUIRED_USE='^^ ( ffmpeg_impl_ffmpeg ffmpeg_impl_libav )'. 2. There is some more work to get ebuilds correct (REQUIRED_USE). However, this is a minor issue compared to the potential mistakes in interpretation of USE='ffmpeg' and USE='libav'. What are your thoughts? In a nutshell, you have a binary choice here, namely ffmpeg or libav as implementation, and instead of one USE flag you want to introduce two (ffmpeg_impl_ffmpeg and ffmpeg_impl_libav), but of the 4 possible combinations only 2 are valid. So you need a REQUIRED_USE to forbid some combinations. Please spare us of this. Ulrich
Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
On 02/02/2015 10:50 AM, Michał Górny wrote: Maybe. Though it still will keep the confusion of !libav meaning ffmpeg. We could remove USE=libav from the tree, leaving only USE=ffmpeg. Then ffmpeg_impl_libav would switch the implementation if USE=ffmpeg is enabled. Maybe a little cleaner but still relies on the implicit thing. Not to mention the user is supposed to set either: FFMPEG_IMPL=libav or: FFMPEG_IMPL= which is nowhere close to sane :). With only one flag, why bother with the USE_EXPAND?
Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
On 02/02/2015 09:06 AM, Michał Górny wrote: Hi, everyone. Just after the news item got published, user Wes mailed me with a suggestion. While I think someone mentioned it earlier in the bikesheds over ffmpeg, I have completely forgotten about it and now I'd like to reconsider it. For this reason, I've reverted the news item while it's still fresh and p.masked the revbumps. The idea is that instead of having USE=libav (that's tangential to USE=ffmpeg and confusing) to use a USE_EXPAND like FFMPEG_IMPL taking either ffmpeg or libav. Now, why... First of all, one of the key points in my news item is that users need to keep consistent state of USE=libav throughout all the packages. Wes pointed out that users are more likely to consider a dedicated variable (USE_EXPAND) in make.conf global than a regular USE flag. Which makes it more likely for them to end up in terrible state full of blockers. Secondly, it avoids the confusion of having USE=ffmpeg and USE=libav being used for completely different purposes. This is not only confusing by users who need to set USE='ffmpeg libav' if they want libav, but also confusing to developers who may end up using the two flags to signify the two implementations. Think of the mess of USE='gtk gtk3'. I might not have followed this discussion close enough; wasn't the end result that USE='ffmpeg' uses ffmpeg and USE='libav' uses libav? As in there will be no more USE='ffmpeg libav' in the future, only USE='libav' for libav? FFMPEG_IMPL feels like a natural extension of USE=ffmpeg. USE=ffmpeg tells to use ffmpeg or a replacement, FFMPEG_IMPL tells what will exactly get used. Much less confusion. I would agree except that as far as I know ffmpeg and libav are not trying to be binary compatible. Fourthly, there's the case of implicity. Right now USE=-libav implies ffmpeg. Therefore, USE=-* implies ffmpeg as well -- which is kinda weird since it's supposedly the non-default. With this solution, USE=-* will result in explicit error asking user to select an implementation. As for the downsides: 1. there is a number of non-meaningful flag combinations. FFMPEG_IMPL='', FFMPEG_IMPL='ffmpeg libav'. They will have to be blocked via REQUIRED_USE='^^ ( ffmpeg_impl_ffmpeg ffmpeg_impl_libav )'. 2. There is some more work to get ebuilds correct (REQUIRED_USE). However, this is a minor issue compared to the potential mistakes in interpretation of USE='ffmpeg' and USE='libav'. What are your thoughts? During the earlier discussion, I was of the opinion that USE='ffmpeg' should just cause a dependency on virtual/ffmpeg and that would solve all the problems. I don't think this is right, though; if ffmpeg and libav are not trying for (or actively avoiding) binary compatibility, why not treat them as separate projects and just add RDEPEND='!media-video/ffmpeg' to libav's ebuild and vice versa? Just my two cents. I'm not a developer, but this seems like the simplest solution to me. Alec
Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
On 3 February 2015 at 00:00, Michael Orlitzky m...@gentoo.org wrote: On 02/02/2015 10:50 AM, Michał Górny wrote: Maybe. Though it still will keep the confusion of !libav meaning ffmpeg. We could remove USE=libav from the tree, leaving only USE=ffmpeg. Then ffmpeg_impl_libav would switch the implementation if USE=ffmpeg is enabled. Maybe a little cleaner but still relies on the implicit thing. Not to mention the user is supposed to set either: FFMPEG_IMPL=libav or: FFMPEG_IMPL= which is nowhere close to sane :). With only one flag, why bother with the USE_EXPAND? Actually, after reading this conversation, I don't think we need the USE_EXPAND. The current solution with USE=ffmpeg libav works. It may not be the cleanest, but the other solution proposed here doesn't add that much. Please restore the news item and unmask the revbumps, so we can get on with business. :) -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
On Tue, 3 Feb 2015, Ben de Groot wrote: Please restore the news item and unmask the revbumps, so we can get on with business. :) +1 pgpf349IEiEzV.pgp Description: PGP signature
Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
On Mon, 2 Feb 2015 17:14:22 +0100 Ulrich Mueller u...@gentoo.org wrote: On Mon, 2 Feb 2015, Alexis Ballier wrote: Ulrich Mueller u...@gentoo.org wrote: In a nutshell, you have a binary choice here, namely ffmpeg or libav as implementation, and instead of one USE flag you want to introduce two (ffmpeg_impl_ffmpeg and ffmpeg_impl_libav), but of the 4 possible combinations only 2 are valid. So you need a REQUIRED_USE to forbid some combinations. We already have three possibilities: ffmpeg, libav or none (only for some packages but they do exist). Right. With the N-1th proposal, it was overseen that USE=-ffmpeg libav should be forbidden by REQUIRED_USE. Why? When you have USE=-ffmpeg, the libav flag is a don't care which is ignored. ffmpeg controls the feature, libav chooses the implementation. This is very clear from the flags' descriptions and was also well explained in the (N-1) news item. Would you offer me a beer each time I'll point you at some user doing USE='-ffmpeg libav' because he wants libav only ? :) With the N-1th proposal, we had two bits (USE='ffmpeg libav') to code 3 states. With the above proposal, we have a kind of unary coding: USE=-ffmpeg means 'none', USE=ffmpeg + ffmpeg_impl_$x means '$x'. Yes, but you would then have 3 bits (i.e. 8 combinations) to code only 3 possible states. Yes, unary is very inefficient :) My real answer is: I don't know, I'm fine with both, but IMHO we should aim at something natural and straightforward for users. (and if I can get free beer, that's even better :) ) Alexis.
Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
On Mon, 2 Feb 2015 15:12:50 +0100 Ulrich Mueller u...@gentoo.org wrote: What are your thoughts? In a nutshell, you have a binary choice here, namely ffmpeg or libav as implementation, and instead of one USE flag you want to introduce two (ffmpeg_impl_ffmpeg and ffmpeg_impl_libav), but of the 4 possible combinations only 2 are valid. So you need a REQUIRED_USE to forbid some combinations. We already have three possibilities: ffmpeg, libav or none (only for some packages but they do exist). With the N-1th proposal, it was overseen that USE=-ffmpeg libav should be forbidden by REQUIRED_USE. With the N-1th proposal, we had two bits (USE='ffmpeg libav') to code 3 states. With the above proposal, we have a kind of unary coding: USE=-ffmpeg means 'none', USE=ffmpeg + ffmpeg_impl_$x means '$x'. I understand your point; I'm not entirely convinced which one is better, but I'm tempted by the simplicity for users of the above unary proposal. Alexis.
Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
On Mon, 2 Feb 2015, Alexis Ballier wrote: Ulrich Mueller u...@gentoo.org wrote: In a nutshell, you have a binary choice here, namely ffmpeg or libav as implementation, and instead of one USE flag you want to introduce two (ffmpeg_impl_ffmpeg and ffmpeg_impl_libav), but of the 4 possible combinations only 2 are valid. So you need a REQUIRED_USE to forbid some combinations. We already have three possibilities: ffmpeg, libav or none (only for some packages but they do exist). Right. With the N-1th proposal, it was overseen that USE=-ffmpeg libav should be forbidden by REQUIRED_USE. Why? When you have USE=-ffmpeg, the libav flag is a don't care which is ignored. ffmpeg controls the feature, libav chooses the implementation. This is very clear from the flags' descriptions and was also well explained in the (N-1) news item. -ffmpeg -libav - none -ffmpeg +libav - none +ffmpeg -libav - ffmpeg +ffmpeg +libav - libav With the N-1th proposal, we had two bits (USE='ffmpeg libav') to code 3 states. With the above proposal, we have a kind of unary coding: USE=-ffmpeg means 'none', USE=ffmpeg + ffmpeg_impl_$x means '$x'. Yes, but you would then have 3 bits (i.e. 8 combinations) to code only 3 possible states. I understand your point; I'm not entirely convinced which one is better, but I'm tempted by the simplicity for users of the above unary proposal. Ulrich pgpQD5Sh7BzBx.pgp Description: PGP signature
Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
On Mon, 2 Feb 2015, Alexis Ballier wrote: On Mon, 2 Feb 2015 17:14:22 +0100 Ulrich Mueller u...@gentoo.org wrote: Why? When you have USE=-ffmpeg, the libav flag is a don't care which is ignored. ffmpeg controls the feature, libav chooses the implementation. This is very clear from the flags' descriptions and was also well explained in the (N-1) news item. Would you offer me a beer each time I'll point you at some user doing USE='-ffmpeg libav' because he wants libav only ? :) -ffmpeg libav is a valid combination, given that ffmpeg can be set per-package, whereas typically there would be only a global setting of libav. It is quite a similar situation to what we had with openmotif and lesstif, where the motif flag enabled the feature, and the lesstif flag chose the implementation. Or is it the name of the flag that is causing confusion? That could be changed. Ulrich pgpizrRHeh90a.pgp Description: PGP signature
Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
Dnia 2015-02-02, o godz. 18:18:14 Alexis Ballier aball...@gentoo.org napisał(a): On Mon, 2 Feb 2015 18:08:01 +0100 Ulrich Mueller u...@gentoo.org wrote: On Mon, 2 Feb 2015, Alexis Ballier wrote: On Mon, 2 Feb 2015 17:14:22 +0100 Ulrich Mueller u...@gentoo.org wrote: Why? When you have USE=-ffmpeg, the libav flag is a don't care which is ignored. ffmpeg controls the feature, libav chooses the implementation. This is very clear from the flags' descriptions and was also well explained in the (N-1) news item. Would you offer me a beer each time I'll point you at some user doing USE='-ffmpeg libav' because he wants libav only ? :) -ffmpeg libav is a valid combination, given that ffmpeg can be set per-package, whereas typically there would be only a global setting of libav. It is quite a similar situation to what we had with openmotif and lesstif, where the motif flag enabled the feature, and the lesstif flag chose the implementation. Even though I got the ffmpeg/libav flags right, the motif situation actually always confused me :/ Or is it the name of the flag that is causing confusion? That could be changed. I guess the flag name isn't helping indeed. The initial proposal wanted to preserve the meaning of the 'ffmpeg' useflag, breaking the symmetry between ffmpeg libav flags. Michal proposed the 'libavcodec' flag to restore it, but IMHO this was even worse. If you happen to have an idea of a correct name for a flag that enables some of 'libavcodec, libavutil, libavformat, libswscale, libavresample, libswresample or libavdevice' support, then please shout. What I find interesting in this proposal is that ffmpeg useflag keeps its old meaning, and we have a symmetric setting for choosing the implementation. Yes. And think of the beauty of: FFMPEG_IMPL=ffmpeg FFMPEG_IMPL=libav You may even imagine it a regular string config, not a USE_EXPAND! Wes has compared this to ruby python. One USE=python|ruby on some packages to enable the optional support, and generic globally set RUBY/PYTHON_TARGETS. -- Best regards, Michał Górny pgpCfkGuerDXT.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
Dnia 2015-02-02, o godz. 18:08:01 Ulrich Mueller u...@gentoo.org napisał(a): On Mon, 2 Feb 2015, Alexis Ballier wrote: On Mon, 2 Feb 2015 17:14:22 +0100 Ulrich Mueller u...@gentoo.org wrote: Why? When you have USE=-ffmpeg, the libav flag is a don't care which is ignored. ffmpeg controls the feature, libav chooses the implementation. This is very clear from the flags' descriptions and was also well explained in the (N-1) news item. Would you offer me a beer each time I'll point you at some user doing USE='-ffmpeg libav' because he wants libav only ? :) -ffmpeg libav is a valid combination, given that ffmpeg can be set per-package, whereas typically there would be only a global setting of libav. It is quite a similar situation to what we had with openmotif and lesstif, where the motif flag enabled the feature, and the lesstif flag chose the implementation. It is valid but USE=libav is then unexpectedly meaningless :). This thread alone shows how confused users are by it. Or is it the name of the flag that is causing confusion? That could be changed. Maybe. But there's no good solution for that either. My USE=avcodec idea brought many complaints... But even then, regular USE flags for this kind of global switch don't work well. Maybe we should do the Arfrever thing. USE=ffmpeg-or-libav and USE=ffmpeg-instead-of-libav. This will avoid most of the confusion, though ffmpeg users will complain that we don't have USE=libav-instead-of-ffmpeg instead. -- Best regards, Michał Górny pgpHfJ_0thvus.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
On Mon, 2 Feb 2015 18:08:01 +0100 Ulrich Mueller u...@gentoo.org wrote: On Mon, 2 Feb 2015, Alexis Ballier wrote: On Mon, 2 Feb 2015 17:14:22 +0100 Ulrich Mueller u...@gentoo.org wrote: Why? When you have USE=-ffmpeg, the libav flag is a don't care which is ignored. ffmpeg controls the feature, libav chooses the implementation. This is very clear from the flags' descriptions and was also well explained in the (N-1) news item. Would you offer me a beer each time I'll point you at some user doing USE='-ffmpeg libav' because he wants libav only ? :) -ffmpeg libav is a valid combination, given that ffmpeg can be set per-package, whereas typically there would be only a global setting of libav. It is quite a similar situation to what we had with openmotif and lesstif, where the motif flag enabled the feature, and the lesstif flag chose the implementation. Even though I got the ffmpeg/libav flags right, the motif situation actually always confused me :/ Or is it the name of the flag that is causing confusion? That could be changed. I guess the flag name isn't helping indeed. The initial proposal wanted to preserve the meaning of the 'ffmpeg' useflag, breaking the symmetry between ffmpeg libav flags. Michal proposed the 'libavcodec' flag to restore it, but IMHO this was even worse. If you happen to have an idea of a correct name for a flag that enables some of 'libavcodec, libavutil, libavformat, libswscale, libavresample, libswresample or libavdevice' support, then please shout. What I find interesting in this proposal is that ffmpeg useflag keeps its old meaning, and we have a symmetric setting for choosing the implementation. Alexis.
Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
Dnia 2015-02-02, o godz. 11:00:59 Michael Orlitzky m...@gentoo.org napisał(a): On 02/02/2015 10:50 AM, Michał Górny wrote: Maybe. Though it still will keep the confusion of !libav meaning ffmpeg. We could remove USE=libav from the tree, leaving only USE=ffmpeg. Then ffmpeg_impl_libav would switch the implementation if USE=ffmpeg is enabled. Wasn't that your point in the first mail? Maybe a little cleaner but still relies on the implicit thing. Not to mention the user is supposed to set either: FFMPEG_IMPL=libav or: FFMPEG_IMPL= which is nowhere close to sane :). With only one flag, why bother with the USE_EXPAND? Because otherwise we're back to USE=libav, only named different and illegally as well (PMS sez _ is reserved for USE_EXPAND). -- Best regards, Michał Górny pgpoluzNtkCla.pgp Description: OpenPGP digital signature
