| Summary: | net-analyzer/wireshark forces choice of one of gtk{2,3} or qt4 or neither | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Jesse Adelman <jesse> |
| Component: | Current packages | Assignee: | Gentoo Netmon project <netmon> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | floppym, kavol, luke-jr+gentoobugs, martin, norman.shulman, openhs, zerochaos |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=508644 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | emerge --info | ||
Created attachment 358496 [details]
emerge --info
(In reply to Jesse Adelman from comment #0) > Yes, I know I can use 'package.use', and will, but that file's use should be optional, not required, at least for *-stable packages. > I disagree with this assertion in general. However, in this case I do think it might be best to just pick best supported toolkit. (In reply to Mike Gilbert from comment #2) > (In reply to Jesse Adelman from comment #0) > > Yes, I know I can use 'package.use', and will, but that file's use should be optional, not required, at least for *-stable packages. > > > > I disagree with this assertion in general. However, in this case I do think > it might be best to just pick best supported toolkit. IUSE="[..] +gtk2 gtk3 [..] qt4 [..]" gtk2 is already the default, but thankfully this is Gentoo so you can override it. Picking more than one will, however, upset the build system, so bailing out early (when a wrong mix of USE flags is found) is the best we can do. It's already there. gtk3 didn't even compile in 1.10.1, qt4 has a novel UI design we shouldn't be pushing on users yet, and gtk2 is still the upstream default. So pick one and be happy with your choice. As the Summary stands it's wrong: you can build the package with neither USE flag (and still get tshark). OK, well, thanks for the feedback. I don't think my "Description" was really read, but whatever. As seen from my emerge --info attachment, I have: "gtk2 gtk3 -qt4" So, from comment 3, I shouldn't have an error from Portage, correct? The ebuild tells portage to pick "gtk2"? At the very least, this is a bit confusing for an end-user like me. But maybe I'm just dense. Cheers. (In reply to Jeroen Roovers from comment #3) > gtk2 is already the default, but thankfully this is Gentoo so you can > override it. Picking more than one will, however, upset the build system, so > bailing out early (when a wrong mix of USE flags is found) is the best we > can do. > Not really; you could simply override invalid combinations in src_configure, which is more user-friendly than a REQUIRED_USE error. For example, if the user has USE="gtk2 gtk3 qt4", just ignore gtk3 and qt4 and pass the gtk2 option to configure. (In reply to Mike Gilbert from comment #5) > Not really; you could simply override invalid combinations in src_configure, > which is more user-friendly than a REQUIRED_USE error. > > For example, if the user has USE="gtk2 gtk3 qt4", just ignore gtk3 and qt4 > and pass the gtk2 option to configure. No, that is one of the reasons why REQUIRED_USE was introduced - to prevent such automagic. User will have installed wireshark with bogus dependency on gtk3 and/or qt4 - that's not good at all. (In reply to Mike Gilbert from comment #5) > Not really; you could simply override invalid combinations in src_configure, > which is more user-friendly than a REQUIRED_USE error. That's not user friendly at all. Trying to figure out why something didn't install eg. a qt gui when I enabled USE=qt4 is no fun. I really like how this is done with recent wireshark versions, but it doesn't play well with the desktop profiles, which currently enable both qt4 and gtk. For added user-friendlyness, qt4 could perhaps be disabled for wireshark in profiles/targets/desktop/package.use ? (In reply to Sergey Popov from comment #6) > No, that is one of the reasons why REQUIRED_USE was introduced - to prevent > such automagic. User will have installed wireshark with bogus dependency on > gtk3 and/or qt4 - that's not good at all. From the devmanual: http://devmanual.gentoo.org/general-concepts/use-flags/index.html#conflicting-use-flags Occasionally, ebuilds will have conflicting USE flags for functionality. Checking for them and returning an error is not a viable solution. Instead, you must pick one of the USE flags in conflict to favour and should alert the user that a particular flag is being used instead. ... In some exceptional cases, above policy would break reverse USE dependencies. To avoid this, the ebuild can specify allowed USE flag combinations with REQUIRED_USE (available in EAPI 4). See section eapi="4" for a description of its syntax. ... 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. I would not consider this to be an "exceptional case" and I can't see how it would break reverse USE dependencies. As for the "bogus" deps, that is easily solved:
gtk2? (
${GTK_COMMON_DEPEND}
>=x11-libs/gtk+-2.4.0:2
)
!gtk2? (
gtk3? (
${GTK_COMMON_DEPEND}
x11-libs/gtk+:3
)
!gtk3? (
dev-qt/qtcore:4
dev-qt/qtgui:4
x11-misc/xdg-utils
)
)
I also wonder if there is a significant difference between the gtk2 and gtk3 UIs; maybe you should just pick one as the GNOME team suggests.
OK, so the quote from the devmanual seems clear, yet the bug is still WONTFIX? :) (In reply to Mike Gilbert from comment #9) > As for the "bogus" deps, that is easily solved: > > gtk2? ( > ${GTK_COMMON_DEPEND} > >=x11-libs/gtk+-2.4.0:2 > ) > !gtk2? ( > gtk3? ( > ${GTK_COMMON_DEPEND} > x11-libs/gtk+:3 > ) > !gtk3? ( > dev-qt/qtcore:4 > dev-qt/qtgui:4 > x11-misc/xdg-utils > ) > ) > > I also wonder if there is a significant difference between the gtk2 and gtk3 > UIs; maybe you should just pick one as the GNOME team suggests. Well, most of recent commits done by Jeroen, it is up to him to decide, but to be honest: ouch, you suggest to replace clear thingie with a bloated USE-flag tricks? Really, i spent around a minute to undestand the whole logic here. >For added user-friendlyness, qt4 could perhaps be disabled for wireshark in >profiles/targets/desktop/package.use ? That's a much better solution IMO - disabling gtk3 and qt4 USE-flags for this package in profiles and let user decide. (In reply to Sergey Popov from comment #11) > (In reply to Mike Gilbert from comment #9) > >For added user-friendlyness, qt4 could perhaps be disabled for wireshark in >profiles/targets/desktop/package.use ? > > That's a much better solution IMO - disabling gtk3 and qt4 USE-flags for > this package in profiles and let user decide. That sounds better than introducing all the horrible USE flag selection logic in ebuilds. It would have to be done in a couple of profiles: targets/serverpackage.use:net-analyzer/wireshark-gtk2 -gtk3 -qt4 targets/desktop/kde/package.use:net-analyzer/wireshark -gtk2 -gtk3 qt4 targets/desktop/gnome/package.use:net-analyzer/wireshark gtk2 -gtk3 -qt4 and I probably forget a lot of other profiles. Anyone feel like fixing the profiles? I think you don't actually need to touch the one for targets/desktop/gnome if you do it in targets/desktop; gnome should inherit the setting. (In reply to Mike Gilbert from comment #13) > I think you don't actually need to touch the one for targets/desktop/gnome > if you do it in targets/desktop; gnome should inherit the setting. looks like "net-analyzer/wireshark -qt4" in targets/desktop/package.use would fix this. I'm going to do that in 24 hour unless anyone has a reason not to. (In reply to Rick Farina (Zero_Chaos) from comment #14) > (In reply to Mike Gilbert from comment #13) > > I think you don't actually need to touch the one for targets/desktop/gnome > > if you do it in targets/desktop; gnome should inherit the setting. > > looks like "net-analyzer/wireshark -qt4" in targets/desktop/package.use > would fix this. I'm going to do that in 24 hour unless anyone has a reason > not to. Of course immediately after I said this, wireshark went and said they are officially switching to the qt4 gui.... Anyone care to comment? qt4 is the default now, and as of the latest in the tree it seems to work fine. I think gtk+ option should be kept for a while. At least according to developer's blog[1]: Quote: "If you’re a power user you should probably keep using the GTK+ flavor for the time being. You should also test the Qt flavor from time to time to see how your workflow will change. Both are installed by default on Windows and Linux." If I may express my opinion regarding the proposed solution -- to put -qt4 to a profile -- I think it is just a workaround. The user should not be forced to choose at emerge time even if she or he puts both gtk3 and qt4 USE flags to make.conf. The default option should be chosen by emerge and user informed by a warn or info message. I leave it up to you, Gentoo developers to figure out how to solve it technically ;-) . So if this bug will be solved by -qt4 in profile then perhaps a new bug should be written to solve such problems in general. 1. https://blog.wireshark.org/2013/10/switching-to-qt/ (In reply to Robert Cernansky from comment #16) > I think gtk+ option should be kept for a while. At least according to > developer's blog[1]: Honestly I hate the QT gui so I'm fine with that EXCEPT for this statement: > >"Both are installed by default on Windows and Linux." > Um, say what? So I checked a clean build and sure enough, it defaults to gtk3 over gtk2 (which I'm never advocating due to known bugs) and building both gtk and qt interfaces. I'm going to see what it takes to remove the limit from the ebuild and just let it build bother interfaces. The build system supports it, and if users have both use flags set then let it be. I'll need some time, but I'm working on this now. (In reply to Rick Farina (Zero_Chaos) from comment #17) > Um, say what? So I checked a clean build and sure enough, it defaults to > gtk3 over gtk2 (which I'm never advocating due to known bugs) and building > both gtk and qt interfaces. I'm going to see what it takes to remove the > limit from the ebuild and just let it build bother interfaces. I have no idea what you are talking about. Get to the point. 1.11.2 supports building either gtk2/3 or none and qt4 or none, separately, or none of these (only build tshark). With USE="gtk* qt4" you get wireshark (GTK+) and wireshark-qt (Qt obviously). Upstream sees qt4 as the future default in the development branch (1.11) but sees gtk3 as the stable interface, whereas gtk2 is deprecated for that branch. Therefore, the 1.11.2 ebuild has IUSE="gtk2 +gtk3 +qt4". The older branches have IUSE defaults that follow the same upstream preferences. This obviously causes problems if you set yourself a KDE or GNOME profile and see $unwanted_USE_flag or $unwanted_UI_lib find its way into the merge list. There are two solutions to this problem: 1) remove the IUSE defaults, ignoring upstream, or 2) fix the profiles for KDE and GNOME. Since you already promised to do 2) in comment #15, I don't see what changed so suddenly for you to post comment #17. Upstream supports building both GTK and Qt UIs, so why is USE='gtk2 qt4' unsupported? :( (In reply to Luke-Jr from comment #19) > Upstream supports building both GTK and Qt UIs, so why is USE='gtk2 qt4' > unsupported? :( Both at once? Have you actually tried it? *** Bug 508806 has been marked as a duplicate of this bug. *** (In reply to Rick Farina (Zero_Chaos) from comment #17) > ... and if users have both use flags set then let it be. please note that currently emerge thinks I have them both even if I have only qt4, see the bug #508806 Let's play out some likely scenarios: A) I drop REQUIRED_USE for the toolkits User runs # USE="gtk2 gtk3 qt4" emerge wireshark and after emerging many many libraries (I am not going to count needlessly installed megabytes and minutes to hours wasted, here) finds out that despite all the effort, wireshark (1.10.x for instance) will use only -one- toolkit, and automagically at that. B) I drop the IUSE defaults KDE user runs # emerge wireshark and ends up with wireshark 1.10.7's Qt interface. Somehow things appear to be "not ready for normal use", "incomplete", "missing", "unavailable" (bug #508644 <= that's not a valid bug report, but it is a very valid complaint against defaulting to USE=qt4) (bug #478824, actual failure). Suddenly the carefully selected IUSE defaults start to make sense. C) I drop IUSE entries for non-default toolkits and support only the One True Toolkit for each branch. Queue the usual complaints about missing options, Gentoo being about choice, etcetera. This argument extends into the KDE/GNOME "rivalry" as a small minority of users pick one and then expect, say, wireshark to support a full KDE/Qt UI, when it never yet has. Having to work with a GTK+ UI in a Qt/KDE environment is apparently worthy of a complaint: despite the Qt option not being available until recently (the 1.10 branch) people have been complaining about this for years. It's not going to stop there either, because in the 1.11 branch GTK+ is deprecated and it will very likely be completely gone once 1.12 is released. So your only option right now is to read the USE flag descriptions, choose carefully and set your local profile accordingly (/etc/portage/profile/package.use most likely). If you have found a novel way to avoid the above scenarios, then you're entirely free to comment on this bug report with the grand plan. I wanted to close the bug report as INVALID or WONTFIX or CANTFIX, but I guess we're all stuck here and closing it will simply generate more similar bug reports. Honestly this is all moot on newer versions of wireshark. If you all care so much then please just use wireshark 1.11.x and have a great day. (In reply to Rick Farina (Zero_Chaos) from comment #24) > Honestly this is all moot on newer versions of wireshark. If you all care > so much then please just use wireshark 1.11.x and have a great day. There is no release schedule for 1.12 yet and 1.11 is obviously not going stable, ever. Preferred solution from my point of view is the one that for example cyrus-sasl uses:
----------------------------
>>> Messages generated by process 19413 on 2012-01-06 02:47:25 CET for package d
ev-libs/cyrus-sasl-2.1.23-r6:
LOG: setup
You have both 'gdbm' and 'berkdb' USE flags enabled.
gdbm will be selected.
----------------------------
So the developer of the ebuild chooses which one (gdbm or berkdb) is the best. User is not _forced_ to choose, yet still _able_ to.
In cases where particular use flag may cause limited functionality or instability (qt in this case?) and user enables it (-gtk +qt) then a warning that informs the user about the situation might be shown.
(In reply to Robert Cernansky from comment #26) > Preferred solution from my point of view is the one that for example > cyrus-sasl uses: Welcome to comment #23, scenario A! > In cases where particular use flag may cause limited functionality or > instability (qt in this case?) and user enables it (-gtk +qt) then a warning > that informs the user about the situation might be shown. Oh, so you get to find out what the warning means after a lengthy build and probably several minutes of puzzlement. In a mitigating scenario A1, where a large tree of DEPEND/RDEPEND conditionals would ensure only the one toolkit is actually emerged, you'd get this: USE=qt4 emerge wireshark [...] [ebuild N] x11-libs/gtk+[...] because without warning, the ebuild has wisely chosen that you are not ready for Qt4 and yet another bunch of wireshark users file bug reports about this awful deception. Welcome to scenario A1! (In reply to Rick Farina (Zero_Chaos) from comment #17) Scenario D, which apparently is being worked on, means that for every graphical toolkit you desire, we do a separate build. We change the build system around so that in each ${WORKDIR}/${P}-${WS_TK} a separately unpacked wireshark's configure is fed the proper toolkit to use. We could go one mighty step further and rebuild only the parts linked to $favourite_TK. I understand perfectly why this scenario is still being worked on after half a year. (In reply to Jeroen Roovers from comment #27) > > Oh, so you get to find out what the warning means after a lengthy build and > probably several minutes of puzzlement. pkg_pretend() was introduced to issue such warnings: The user sees the warning before any deps are being built. > where a large tree of DEPEND/RDEPEND conditionals How about bringing this up on the dev mailing list: Perhaps one should think about a future EAPI which simplifies such things; something like REQUIRED_USE_AUTOCHOICE=... In fact, I had an ebuild which had to hardcode a browser into the binary. Avoiding REQUIRED_USE by autoselecting a default choice with correct RDEPENDS is really a PITA, and the code doubles with any new browser choice added... For the present time, I have added "<wireshark-1.11.0 -qt4" to desktop profile's package.use which should make this easy for most users. Hopefully wireshark will release a new stable with the flexibility of 1.11.x soon and we can just build everything the user wants at once without rebuilding all of wireshark for basically no reason. *** Bug 511432 has been marked as a duplicate of this bug. *** (In reply to Rick Farina (Zero_Chaos) from comment #30) Fixed, then. |
I thought that when there were choices like this that a user made, the ebuild devs would just choose the "most likely" satisfactory answer, if indeed they cannot coexist. As it stands, if I'm not mistaken, the present at-most-one-of USE restriction means that I have to explicitly make a choice among the three, which forces a choice for my whole system. Yes, I know I can use 'package.use', and will, but that file's use should be optional, not required, at least for *-stable packages. Thanks! STILL LOVE GENTOO, EVEN AFTER ALL THESE BEERS. ;) --- !!! Problem resolving dependencies for net-analyzer/wireshark from @selected !!! The ebuild selected to satisfy "net-analyzer/wireshark" has unmet requirements. - net-analyzer/wireshark-1.10.2::gentoo USE="caps crypt gtk2 gtk3 ipv6 kerberos lua pcap smi ssl zlib -adns -doc -doc-pdf -filecaps -geoip -libadns -netlink -portaudio -qt4 (-selinux)" The following REQUIRED_USE flag constraints are unsatisfied: at-most-one-of ( gtk2 gtk3 qt4 ) The above constraints are a subset of the following complete expression: at-most-one-of ( gtk2 gtk3 qt4 ) ssl? ( crypt ) (dependency required by "@selected" [set]) (dependency required by "@world" [argument]) ---