This is a end application and not a library, using REQUIRED_USE here is unnecessary and the ebuild simply do the correct thing transparently. http://devmanual.gentoo.org/general-concepts/use-flags/index.html#conflicting-use-flags "Note: In order to avoid forcing users to micro-manage flags too much, REQUIRED_USE should be used sparingly. Follow the normal policy whenever it is possible to do a build that will presumably suit the user's needs. " Futhermore, USE="lame" shouldn't be used in combination with USE="encode" since USE="lame" implies encoder on it's own. So either, - Stick to USE="lame" and use it alone. - Rename USE="lame" to USE="mp3" and use it together with USE="encode"
Fixed in CVS, thank-you for the report. + 23 May 2012; Michael Palimaka <kensington@gentoo.org> k3b-2.0.2-r3.ebuild: + Remove REQUIRED_USE in favour of letting affected use flags work on their own. + Fixes bug #417235 by Samuli Suominen <ssuominen@gentoo.org>.
(In reply to comment #0) > This is a end application and not a library, using REQUIRED_USE here is > unnecessary and the ebuild simply do the correct thing transparently. > > http://devmanual.gentoo.org/general-concepts/use-flags/index. > html#conflicting-use-flags > > "Note: > > In order to avoid forcing users to micro-manage flags too much, REQUIRED_USE > should be used sparingly. Follow the normal policy whenever it is possible > to do a build that will presumably suit the user's needs. " > > Futhermore, USE="lame" shouldn't be used in combination with USE="encode" > since USE="lame" implies encoder on it's own. > > So either, > - Stick to USE="lame" and use it alone. I'm reopening since this one was chosen and it's not really appropriate since we use USE=encode to enable/disable encoder support in k3b without exceptions. If we are to use 'lame' alone - we need to remove 'encode' USE flag completely. Which wouldn't be bad idea actually.
USE flags removed: - encode (spurious, as shown here) - wav (useless, plugin doesn't bring external deps, always enabling instead)
Hi, Please revert this. You are now making mandatory to transform k3b into a multimedia/video encoding tool. Some users do not want to bother with that and want to have a k3b that is *only* a tool to burn ISO and data cd/dvd...
(In reply to comment #4) > Hi, > > Please revert this. Which part, and why? > You are now making mandatory to transform k3b into a > multimedia/video encoding tool. Some users do not want to bother with that > and want to have a k3b that is *only* a tool to burn ISO and data cd/dvd... This doesn't make any sense.
(In reply to comment #5) > (In reply to comment #4) > > Hi, > > > > Please revert this. > > Which part, and why? Sorry for not being precise: the removing of the "encode" USE flag > > > You are now making mandatory to transform k3b into a > > multimedia/video encoding tool. Some users do not want to bother with that > > and want to have a k3b that is *only* a tool to burn ISO and data cd/dvd... > > This doesn't make any sense. Why ? Now I'm forced to install encoding dependencies that I will never ever use, update those unused dependencies, have unused code path in k3b, potentially dealing with more bugs on features I do not want. I want to use k3b as a data burner tool, not a video DVD or mp3 CD maker... kb3 let the opportunity to disable this, and the previous ebuild honored this possibility. Why remove it now ? For me, such USE flag removal is just a regression. Removing USE flags for small features with no depends, perfect, I'm fine with this. But removing USE flags for *big* features that brings more dependencies... Sorry, I cannot agree. This change looks strange to me and is far away from what I was used to with Gentoo...
(In reply to comment #6) > > > You are now making mandatory to transform k3b into a > > > multimedia/video encoding tool. Some users do not want to bother with that > > > and want to have a k3b that is *only* a tool to burn ISO and data cd/dvd... > > > > This doesn't make any sense. > > Why ? > Now I'm forced to install encoding dependencies that I will never ever use, > update those unused dependencies, have unused code path in k3b, potentially > dealing with more bugs on features I do not want. I want to use k3b as a > data burner tool, not a video DVD or mp3 CD maker... http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-cdr/k3b/k3b-2.0.2-r3.ebuild?r1=1.2&r2=1.3 Looking at above commit, disabling USE="dvd" will accomplish what you are asking for, but then it will not also pull in dvd+rw-tools, and command growisofs and others are never getting emerged. So without checking the source tree, you might be on to something here, USE="dvd" handling is at least broken now.
As in, talking about reverting is propably too much, but indeed it doesn't look quite right yet.
Please do elaborate. All encoders where previously governed by USE=encode + USE=${particular_encoder_backend}. Sth like if use encode && use lame then enable lame encoder Then, someone said, "USE="-encode lame" doesn't make sense and moved USE=lame and USE=sox out of USE="encode" way. And then we got inconsistency as only lame & sox was moved out of USE=encode governance. Then I fixed this inconsistency by removing now redundant USE=encode flag, so encoder plugins are now governed by USE="particular_encodee_backend}. And it's bad again? If you don't want encoders (no dependencies for encoders) -> set USE="-sox -lame -dvd -vorbis" and problem solved. The same you can do for audio decoders (mad, also vorbis, ffmpeg, flac...) So just disable respective USE flags. Yes USE="dvd" become a bit vague after USE="encode" removal. I can restore USE="encode" like it was before (and I preferred it that way) - but then anyone complaining about "USE="-encode lame" will be shot on sight.
(In reply to comment #9) > Please do elaborate. All encoders where previously governed by USE=encode + > USE=${particular_encoder_backend}. > > Sth like > > if use encode && use lame then enable lame encoder > > Then, someone said, "USE="-encode lame" doesn't make sense and moved > USE=lame and USE=sox out of USE="encode" way. And then we got inconsistency > as only lame & sox was moved out of USE=encode governance. > > Then I fixed this inconsistency by removing now redundant USE=encode flag, > so encoder plugins are now governed by USE="particular_encodee_backend}. > > And it's bad again? No, I have no problem with that. > If you don't want encoders (no dependencies for encoders) -> set USE="-sox > -lame -dvd -vorbis" and problem solved. > The same you can do for audio decoders (mad, also vorbis, ffmpeg, flac...) > > So just disable respective USE flags. Yes USE="dvd" become a bit vague after > USE="encode" removal. Yes and if I do not want encoders, I must set -dvd, so I cannot burn DVD anymore because growisofs is not pulled anymore as said by Samuli. That's the problem. Now use dvd enable some video encoding feature instead of simply to allow to burn DVD > I can restore USE="encode" like it was before (and I preferred it that way) > - but then anyone complaining about "USE="-encode lame" will be shot on > sight. If you want to keep the "encoder plugins are now governed by USE="particular_encodee_backend", maybe add a "video-dvd" USE flag or something like that that would allow to split burning data DVD which only needs growisofs from editing video dvd ?
(In reply to comment #9) > if use encode && use lame then enable lame encoder lame is encoder and USE="lame" in itself implies USE="encode". When you set USE="lame" you are saying "I want the Lame MP3 encoder." and you don't need to put USE="encode" in that mix anymore. USE="encode" is designed to guard flags like mp3 and aac, for example, mp3? ( media-sound/mpg123 encode? ( media-sound/lame ) ) aac? ( media-libs/faad2 encode? ( media-libs/faac ) ) To clarify: You don't need USE="encode" with USE="lame" because _LAME is an encoder_. You don't need 2 USE flags for setting 1 option. The rest of the USE="encode" usage was fine in k3b, just not with this one particular flag If you want to cover the lame dependency with USE="encode" in k3b, rename the flag to "mp3" so it makes sense to guard it with USE="encode" too. Sorry if that wasn't clear before, I hope it's now.
(In reply to comment #9) > I can restore USE="encode" like it was before (and I preferred it that way) Sounds fine. > - but then anyone complaining about "USE="-encode lame" will be shot on > sight. IMO this setup needs REQUIRED_USE, since it makes no sense to have a flag setting that can silently do nothing. I agree with Samuli though - having a situation where REQUIRED_USE is needed should be avoided where possible.
It looks like transcode is not linked against (just called), so another option is keeping the ebuild the way it is, but dropping transcode as a dependency and adding an elog message about it instead.
> - Rename USE="lame" to USE="mp3" and use it together with USE="encode" After discussing this issue in the KDE team meeting, we decided on this option. + 25 Aug 2012; Michael Palimaka <kensington@gentoo.org> +k3b-2.0.2-r4.ebuild: + Restore encode USE flag and REQUIRED_USE, and rename lame -> mp3 as per KDE + team meeting.
Thanks. But there is one thing missing in 2.0.2-r4: the transcode dependency should be under the encode USE flag ;) @@ -52,7 +52,7 @@ virtual/cdrtools dvd? ( >=app-cdr/dvd+rw-tools-7 - media-video/transcode[dvd] + encode? ( media-video/transcode[dvd] ) ) emovix? ( media-video/emovix ) sox? ( media-sound/sox )
(In reply to comment #15) > Thanks. > > But there is one thing missing in 2.0.2-r4: the transcode dependency should > be under the encode USE flag ;) I believe this is the case because according to the docs, transcode is used for DVD ripping and not just for encoding. Does k3b exhibit different behaviour in reality?
For data dvd, there is absolutely no need for transcode. This was correct in the 2.0.2-r1 ebuild. From the doc, I read transcode is needed for : - DVD ripping with the transcode tools - Support for automatic clipping - DivX/XviD encoding For me, dvd ripping looks like a synonym for "encode" USE flag (encoding a DVD to divx).
(In reply to comment #17) > For data dvd, there is absolutely no need for transcode. This was correct in > the 2.0.2-r1 ebuild. Thanks, fixed.
*** Bug 509562 has been marked as a duplicate of this bug. ***
