Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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.