rdeps (deps are similar)... !<x11-libs/openmotif-2.1.30-r13 !=x11-libs/openmotif-2.2.2* !=x11-libs/openmotif-2.2.3 !=x11-libs/openmotif-2.2.3-r1 !=x11-libs/openmotif-2.2.3-r2 !=x11-libs/openmotif-2.2.3-r3 !=x11-libs/openmotif-2.2.3-r4 !=x11-libs/openmotif-2.2.3-r5 !=x11-libs/openmotif-2.2.3-r6 !<x11-libs/lesstif-0.93.94-r4 !=x11-libs/lesstif-0.93.97 !=x11-libs/lesstif-0.94.0* app-shells/bash Offhand... this is a built in land mine. Instead of specifying what's usable, it's specifying everything that will cause it to explode. Offhand... these deps could be converted over to a || (), thus whatever the user has merged would be used, or portage would force an upgrade. Jason, comments? The deps in place are whacky imo... offered solution isn't necessarily any better, but _something_ should be doable to make it saner.
*** Bug 116727 has been marked as a duplicate of this bug. ***
This is causing trouble when doing an emerge -auD on a stable x86 system: demokrit ~ # emerge -auDv world These are the packages that I would merge, in order: Calculating world dependencies ...done! [blocks B ] =x11-libs/openmotif-2.2.3-r3 (is blocking x11-libs/motif-config-0.9) [ebuild N ] x11-libs/motif-config-0.9 0 kB [ebuild U ] x11-libs/openmotif-2.2.3-r8 [2.2.3-r3] 0 kB [ebuild U ] media-sound/alsa-headers-1.0.10 [1.0.10_rc3] 0 kB ....... I really think this is a portage bug: portage should note that the blocking package is on its way out, and that when the emerge has completed, there will be no trouble. Just my .02 Euro :-)
Not a portage bug, the problem is that the ebuild is specifying everything it *cannot* work with rather then specifying what it cannot work with. A smarter resolver would unmerge all of the blockers, but that still doesn't ixnay the fact the deps are structured in reverse. Write your deps so they specify what you can work with, rather then writing them stating what they won't. Sounds odd, but the former is easier on resolvers, and works for our particular resolver.
Yes, I can see that it is unusual - but is it even possible to specify that IF a specific package is installed, it must only be this or that version? Without requirering that package to be installed, that is. I guess that is what the ebuild it trying to do. /Jakob
*** Bug 118121 has been marked as a duplicate of this bug. ***
*** Bug 121926 has been marked as a duplicate of this bug. ***
the thing is that all openmotif versions that are not motif-config versions have to be removed before installing motif-config
Re-assign wrt Bug 23545, maintainer retired.
Jeroen: You touched this once or twice....would you be interested in maintaining and fixing this? :) Remove yourself if not, I just really want to see this bug closed. Jason: Or maybe you? You touched the openmotif stuff atleast once :)
(In reply to comment #9) Mark, this whole motif-config idea plain needs to die... You can't have something like motif-config or eselect-motif for binary-incompatible stuff for starters, see Bug 29388; plus one variant of this horrible fugly toolkit is more than enough to maintain for legacy apps that haven't switched to something decent yet. So, the quick solution would be: - pick up *one* motif implementation - fix dependencies accordingly - punt motif-config and the other two implementations - punt anything that doesn't compile/work with the chosen motif implementation because noone's interested in such cruft
Jakub: That's fine by me...someone just has to do something...please :)
http://dev.gentooexperimental.org/~jakub/motif.txt A quick look suggests that the only thing in the whole tree that requires a x11-libs/lesstif and doesn't work with x11-libs/openmotif would be those two obsolete sci-mathematics/geomview versions. The solution looks pretty obvious to me then. (And just to make myself rather clear - no, moaning that A rocks and B sucks, that Gentoo is all about choice and similar is totally irrelevant because what we have now is heavily broken and there's no interest in maintaining the stuff, let alone in multiple redundant implementations).
OK, lets try to move things somewhere: @ emacs: app-editors/emacs-21.4-{r4,r14} - can we please get rid of USE=lesstif there? @ tex: app-text/tetex-3.0_p1-r6 - can we please get of USE=lesstif there (or better said, in tetex-3 eclass)? @ cjk: can we please remove app-text/xdvik-22.84.5? @ common-lisp: dev-lisp/cmucl - can we please get rid of USE=lesstif there? @ sci-geosciences: sci-geosciences/gempak-5.7.2_p2 - sticking virtual/motif !x11-libs/lesstif to DEPEND doesn't make much sense to me, why don't you just depend on openmotif directly? sci-mathematics/geomview was already cleaned-up since Comment #12, so all good for x11-libs/lesstif removal, allowing us to get rid of the horrible motif-config thing eventually, and sorting out this huge mess.
(In reply to comment #13) > @ emacs: app-editors/emacs-21.4-{r4,r14} - can we please get rid of > USE=lesstif there? Will virtual/motif go away, too? I.e., at the moment we depend on: lesstif? ( x11-libs/lesstif ) !lesstif? ( >=x11-libs/openmotif-2.1.30 ) Should this be changed to virtual/motif (as it is already the case for >=emacs-22.1) or to x11-libs/openmotif?
(In reply to comment #14) > (In reply to comment #13) > > @ emacs: app-editors/emacs-21.4-{r4,r14} - can we please get rid of > > USE=lesstif there? > > Will virtual/motif go away, too? No, not ATM at least, since we desperately lack volunteers and there's no issue with leaving the virtual in place even if it's going to have just one provider. :) To clarify here a bit more - the goal (for now) is to get rid of x11-libs/lesstif at least; at that point we stop breaking lots of stuff b/c this whole concept plain can't work for binary-incompatible implementations (discussed in great detail on other bugs). For now, mitigating issues like those mentioned in bug 117458 comment #6 would be nice progress to see. :) Once that's done, openmotif should be slotted in a *proper* way so that no such utility like motif-config is required, it really doesn't make sense to have a tool that switches between different slots of a *library* to me... We can rename it and keep the shared stuff that'd collide otherwise between slots, but you totally cannot expect apps to remain working if you switch the motif libs to different ABI, that's just crazy. Also, do we really need the slotting here? Etc. etc. But, that's beyond the scope of this bug.
I know there been trouble with lesstif, but I can't make the *tif to act and look as nice as lesstif. So I would want to keep lesstif as long as there aren't a proper replacement.
(In reply to comment #16) > I know there been trouble with lesstif, but I can't make the *tif to act and > look as nice as lesstif. So I would want to keep lesstif as long as there > aren't a proper replacement. Re-read Comment #12 please. Once again: 1/ motif-config cannot work it heavily breaks stuff 2/ openmotif slotting cannot work as it is either 3/ you'd get blockers between lesstif and openmotif anyway once motif-config is gone 4/ there's zero interest in maintaining either of the implementations in Gentoo and this this whole toolkit regardless of implementation is an obsolete 80's-style piece of *censored* that makes one's eyes bleed Solution -> keep exactly *one* implementation and *one* slot of this thing in the tree and reduce the maintenance overhead to a plain minimum. Alternatives include nuking everything that depends on virtual/motif from the tree altogether if that's what you prefer. The above is not going to change no matter how much people complain b/c there's noone to fix and maintain this mess.
Removed lesstif USE flag from emacs-21.4-r14. I won't bother to fix -r4 since it will be removed anyway, as soon as -r14 is stable (that is bug #197313).
(In reply to comment #13) > @ tex: app-text/tetex-3.0_p1-r6 - can we please get of USE=lesstif there (or > better said, in tetex-3 eclass)? done
(In reply to comment #13) > dev-lisp/cmucl - can we please get rid of USE=lesstif there? Done.
So, what is left? > @ cjk: can we please remove app-text/xdvik-22.84.5? Trivial. > @ sci-geosciences: sci-geosciences/gempak-5.7.2_p2 - sticking virtual/motif > !x11-libs/lesstif to DEPEND doesn't make much sense to me, why don't you > just depend on openmotif directly? This is a blocker, not a dependency, so it doesn't hinder lesstif removal. So, only thing is to remove the old xdvik version, and then lesstif can go away. Or am I missing something?
(In reply to comment #21) > This is a blocker, not a dependency, so it doesn't hinder lesstif removal. Well, ebuilds should state directly what they need and not what they don't want. Similar stuff messes with dependency resolver, this one IMO makes dependency calculation go kaboom when virtual/motif is satisfied with lesstif. But no, that doesn't hinder lesstif removal. > So, only thing is to remove the old xdvik version, and then lesstif can go > away. Or am I missing something? Yeah. Once xdvik is done, need a saner motif-config commited (see Bug 91951) and stabilized together with latest openmotif, once that's done, nuke the slotting.
xdvik done, thanks aballier.
All blocking stuff done from Comment #13 done here, sci-geosciences please sanitize the gempak deps a bit, thanks. Now we need the motif-config-0.10-r2 ebuild from Bug 91951 Comment #6 committed and stabilized with x11-libs/openmotif-2.3.0 (Bug 204265) to get rid of the mess.
Fixed in motif-config-0.10-r2
(In reply to comment #25) > Fixed in motif-config-0.10-r2 > no it isn't: emerge -uavD gives me [ebuild U ] x11-libs/motif-config-0.10-r2 [0.10-r1] 9 kB [blocks B ] <x11-libs/openmotif-2.3.0 (is blocking x11-libs/motif-config-0.10-r2) however, the ebuilds seem to be ok: /usr/portage/x11-libs/motif-config/motif-config-0.10-r2.ebuild: > DEPEND="!<x11-libs/openmotif-2.3.0 > ... /usr/portage/x11-libs/openmotif/openmotif-2.3.0.ebuild > RDEPEND=" > ... > >=x11-libs/motif-config-0.9" I'm guessing this is a peculiar bug where version numbers are compared alphabetically, and 0.10 >= 0.9 thus evaluates to false... I wouldn't expect this kind of bug in portage though, does anyone know more about this? I think i'll go look if there's another bug filed for this but if there isn't i'll open a new one - since it doesn't really seem related to this... (for the record, I'm a gentoo user for 2 years, I'd like to be a gentoo dev if I had the time but for now I'm happy with just using gentoo and finding out why things don't work)
(In reply to comment #26) > no it isn't: > emerge -uavD gives me > > [ebuild U ] x11-libs/motif-config-0.10-r2 [0.10-r1] 9 kB > [blocks B ] <x11-libs/openmotif-2.3.0 (is blocking > x11-libs/motif-config-0.10-r2) Yeah of course, read the comments in the motif-config ebuild. The blocker is staying there so that you unmerge everything before updating. Not a bug.
ah. ok (odd, it's the first time I come across this practice afaik.) but the thing that confuses me is that motif-config asks for openmotif-2.3.0 or higher. I _have_ 2.3.0 installed on my system (and no older versions besides it). so why is it complaining?
(In reply to comment #28) > but the thing that confuses me is that motif-config asks for openmotif-2.3.0 or > higher. I _have_ 2.3.0 installed on my system (and no older versions besides > it). so why is it complaining? Because the thing is (incorrectly) slotted. You must unmerge everything but the latest version.
*** Bug 211065 has been marked as a duplicate of this bug. ***
*** Bug 212796 has been marked as a duplicate of this bug. ***
Reopening, since x11-libs/motif-config is still in the tree. Waiting for stabilisation of openmotif-2.3.0-r1 in bug 211696, then it can be punted.
(In reply to comment #32) > Waiting for stabilisation of openmotif-2.3.0-r1 in bug 211696, then it > can be punted. Package masked for removal.
(In reply to comment #13) > @ sci-geosciences: sci-geosciences/gempak-5.7.2_p2 - sticking virtual/motif > !x11-libs/lesstif to DEPEND doesn't make much sense to me, why don't you > just depend on openmotif directly? No response since 4 months, so I've fixed this myself.
x11-libs/motif-config removed. Closing.
