Bugzilla Bug 210021

Works in progress... :P

http://dev.gentooexperimental.org/~jakub/overlay/x11-libs/openmotif/

TODO: wipe useless functions from motif-config

Should be all done and ready for testing in ~arch...

> http://dev.gentooexperimental.org/~jakub/overlay/x11-libs/openmotif/

In motif-config-2.3, you probably want an "exit 0" in get_inc_path, too:

 get_inc_path() {
        echo "/usr/include/"
+       exit 0
 }

Committed (still package.masked) with two changes:
- The demo binaries definitely don't belong into /usr/share/doc, so I removed
  them completely. If there is demand for them (what I doubt) we may think
about
  installing them in /usr/libexec/openmotif.
- Fixed symlink for system.mwmrc; this was already broken in motif-config.

(In reply to comment #4)
> - The demo binaries definitely don't belong into /usr/share/doc, so I removed
>   them completely. If there is demand for them (what I doubt) we may think
> about
>   installing them in /usr/libexec/openmotif.

They originally were in /usr/libexec/openmotif, then I moved them to the demos
src stuff because I disliked the location... Shrug. There's no way to disable
compiling them without lots of messing, doesn't make much sense to compile them
and delete them right after. :)

(In reply to comment #5)
> There's no way to disable compiling them without lots of messing,
> doesn't make much sense to compile them and delete them right after. :)

I didn't spend attention to this because compile time for the demos is only a
small fraction of the total time. But you are right of course; it is more
intelligent not to compile the demos in the first place. Fixed version
committed.

Meh, IIRC I tried this sed approach but it didn't work for some reason... Maybe
I just screwed and did the sed on a wrong file, anyway I'll test when I have
more time. :)

Could I ask why we are unslotting this?  I have a binary application that needs
openmotif 2.2, and I guess there are other people with the same problem.  

(In reply to comment #8)
> Could I ask why we are unslotting this?  I have a binary application that
> needs openmotif 2.2, and I guess there are other people with the same problem.

We could think about an ebuild for openmotif 2.2 that installs only the shared
libraries, i.e. lib{Xm,Mrm,Uil}.so*. The libraries are properly slotted: .so.3
for openmotif-2.2 and .so.4 for openmotif-2.3, so they could be installed
alongside each other in /usr/$(get_libdir)/.

Would such a solution suit your needs?

(In reply to comment #9)
> Would such a solution suit your needs?

It would most certainly! Thanks in advance. 

(In reply to comment #8)
> Could I ask why we are unslotting this?  I have a binary application that needs
> openmotif 2.2, and I guess there are other people with the same problem.  

Because it's utterly broken (see Bug 204249 and the blockers there). And I'm
definitely against any re-slotting of this legacy crap.

Created an attachment (id=143578) [details]
Proposed ebuild to have openmotif-2.2 libraries without interfering with more
recent versions

Does the attached ebuild seem like an acceptable solution?
It's supposed to install just some .so.3 files in /usr/$(get_libdir) (apart
from some cruft in /usr/share/doc).  

So, once again:

- *nothing* in the tree needs this
- there's *noone* to maintain this
- if something doesn't work with an openmotif version that changed about *5*
files altogether in the source code since 2002 (unpack openmotif-2.3.0 and
check the timestamps) then it's utter junk that deserves to die a painful
death.

So, I'd suggest you go maintain this cruft in your overlay together with your
binary-only stuff, instead of causing more maintenance burden with this that
noone's interested in maintaining at all.

I am only trying to help.  Thank you for making me feel so welcome to do so.  

<http://www.motifzone.org/index.php?module=pagemaster&PAGE_user_op=view_page&PAGE_id=75&MMN_position=74:3>
says:
| Open Motif 2.3 is an updated version of 2.2. Any applications
| built against a previous 2.x release of Open Motif will be binary
| compatible with this release.

So in principle, binary applications should be compatible. However, upstream
has changed the library slot from 3 to 4, so they may not find the library.

Stefaan, does application work if you add a symlink from 
lib{Xm,Mrm,Uil}.so.4 to *.so.3? (This solution was already taken for
net-misc/icaclient.)

(In reply to comment #14)
> I am only trying to help.  Thank you for making me feel so welcome to do so.  

Well the only help here is making the whole horrible toolkit die. And yeah
what's  said above, the ABI change doesn't make absolutely any sense - the only
'development' this horrible thing has seen since 2002 have been the loads of
security fixes we have in the 2.2.x ebuilds.

It bugs me that upstream made a library version change to .4, if there weren't
any binary compatibility changes.  If there were, then this gets rather ugly
for people who rely on binary only commercial packages.  Binary only commercial
packages exist and as much as some people seem to think they suck, for alot of
us in the real world, there's no choice.

If the upstream decided to make the bump to .4, I think it's in gentoo's best
interest to maintain a .3 library that can be installed to appease those
"stupid" binary only commercial packages. Isn't the point of having versioned
shared libraries, so things can co-exist and make older applications happy?

(In reply to comment #17)
> It bugs me that upstream made a library version change to .4, if there weren't
> any binary compatibility changes. 

You can ask upstream why did they do such stupid thing. Seeing this:

<snip>
Open Motif 2.3 is an updated version of 2.2. Any applications
built against a previous 2.x release of Open Motif will be binary
compatible with this release.
</snip>

they don't even seem to grok what's SONAME good for, apparently, so all I can
do is wish you a good luck with that investigation.

> If there were, then this gets rather ugly for people who rely on binary only 
> commercial packages.  Binary only commercial packages exist and as much as 
> some people seem to think they suck, for alot of us in the real world, there's 

You paid for it, you go complain to your vendor that it's incompatible/broken
with 'recent' openmotif versions.

> If the upstream decided to make the bump to .4, I think it's in gentoo's best
> interest to maintain a .3 library that can be installed to appease those
> "stupid" binary only commercial packages. Isn't the point of having versioned
> shared libraries, so things can co-exist and make older applications happy?

Once again, as stated multiple times on multiple other bugs - there's *no*
maintainer for this and there's absolutely *zero* interest in maintaining
anything but a single slot and single implementation of this legacy toolkit on
Gentoo. If commercial stuff breaks for you, well sorry but that's not our
fault,  there's nothing in out repository that'd require slotting or anything
like that.
Create the symlinks, use a wrapper script to run that and move on.

So, please lets stop beating a dead horse finally, it won't go anywhere. 

I guess we should at least add some elog message to pkg_postinst. Would
something like the following be appropriate:

| Gentoo is no longer providing slotted Open Motif libraries. See bug 204249
| and its dependencies for the reasons.
|
| From the Open Motif 2.3.0 (upstream) release notes:
| "Open Motif 2.3 is an updated version of 2.2. Any applications built
| against a previous 2.x release of Open Motif will be binary compatible
| with this release."
|
| If you have binary-only applications requiring libXm.so.3, you may
| therefore create a symlink from libXm.so.3 to libXm.so.4. Please note,
| however, that there will be no Gentoo support for this.

I agree to removing old buggy libs
the only problem is that many crap apps (namely Xilinx) still rely on openmotif
< 2.3
the symlink method seems to work, so it's true that they're binary compatible

you'd only need to automate the linking procedure and openmotif-2.2 is easily
trashable

(In reply to comment #19)
> I guess we should at least add some elog message to pkg_postinst. Would
> something like the following be appropriate:
> 
> | Gentoo is no longer providing slotted Open Motif libraries. See bug 204249
> | and its dependencies for the reasons.
> |
> | From the Open Motif 2.3.0 (upstream) release notes:
> | "Open Motif 2.3 is an updated version of 2.2. Any applications built
> | against a previous 2.x release of Open Motif will be binary compatible
> | with this release."
> |
> | If you have binary-only applications requiring libXm.so.3, you may
> | therefore create a symlink from libXm.so.3 to libXm.so.4. Please note,
> | however, that there will be no Gentoo support for this.
> 

(In reply to comment #20)
> you'd only need to automate the linking procedure [...]

Easy: we just had to add a USE flag. But it is a gross hack, so I'm not sure if
we should do this. Also, the symlink will confuse revdep-rebuild.

(In reply to comment #21)
> (In reply to comment #20)
> > you'd only need to automate the linking procedure [...]
> 
> Easy: we just had to add a USE flag. But it is a gross hack, so I'm not sure if
> we should do this. Also, the symlink will confuse revdep-rebuild.

s/confuse/break... So - not a viable solution really; you are on your own with
out-of-the-tree stuff.

(In reply to comment #21)
> (In reply to comment #20)
> > you'd only need to automate the linking procedure [...]
> 
> Easy: we just had to add a USE flag. But it is a gross hack, so I'm not sure if
> we should do this. Also, the symlink will confuse revdep-rebuild.
> 

It's either that or a separate package that only installs the libraries, I
don't see any other alternatives (and no, I don't follow the out-of-tree logic
at all, I don't feel like abandoning users simply because they need
closed-source and/or third-party software).  
If a symlink confuses revdep-rebuild, we could simply copy the library to the
old soname (which is maybe even dirtier :) )

I heavily regret to have invested my time into *fixing* openmotif for users.
Instead of thank you, I only get rants from bugs into my mailbox, people
moaning about third-party crap that 'needs' slotting, people failing to
understand that lesstif and openmotif cannot coexist on the same system and
people suggesting nonsensical completely unneeded hacks to be introduced in the
(finally sane) ebuild.

Do guys whatever you want in the ebuild - just because it's oooooh so horribly
difficult for users who have already installed a third-party unsupported by
Gentoo stuff *manually* to also *manually* create a compat symlink somewhere in
/opt and start the broken cruft via a wrapper script. Exactly like
net-misc/icaclient does. openmotif-2.3.0-r1 even provides a postinstall about
this.

I don't care any more, closing this bug as there's nothing left to fix here
anyway. Stabilization handled in Bug 204265, after that's finished there will
be no way to install 2.2 slot anywhere but it can rot in the tree indefinitely 
so that we don't 'abandon' users.

Created an attachment (id=144451) [details]
Ebuild for legacy Open Motif 2.2 libraries

@Stefaan: For reference, I attach an updated version of the 2.2.3 ebuild,
following our discussion on IRC.

In case we should add this at all, it should go to a different package, like
"openmotif-legacy" or "openmotif-compat", so nothing in the Portage tree will
depend on it.

(In reply to comment #24)
> Stabilization handled in Bug 204265, after that's finished there will be no
> way to install 2.2 slot anywhere but it can rot in the tree indefinitely so
> that we don't 'abandon' users.

This is no solution. We should remove both the 2.2 slot and motif-config as
soon as 2.3 is stable. They are both no longer functional.

I really don't grok what are you trying to do here???

<snip>
emake -j1 -C lib DESTDIR="${D}" install-exec || die "emake install failed"
# cleanup
rm -fR "${D}"/usr/$(get_libdir)/*.{so,la,a}
</snip>

You've installed and then just nuked the whole thing.

(In reply to comment #26)
> emake -j1 -C lib DESTDIR="${D}" install-exec || die "emake install failed"
> # cleanup
> rm -fR "${D}"/usr/$(get_libdir)/*.{so,la,a}
> 
> You've installed and then just nuked the whole thing.

That wouldn't make much sense. ;-) Only the static libraries and the *.so
symlinks are removed. What is left are the shared libraries and the *.so.3
symlinks. This is all what is needed.

Created an attachment (id=144666) [details]
Ebuild for legacy Open Motif 2.2 libraries

Updated ebuild to install also libUil. (Some third-party applications need it,
see bug 53759.)

I think the way to go is to add this as x11-libs/openmotif-compat, and keep it
there for some limited time. Regular systems will never install it (nothing
depends on it), but we don't desert users who need it for legacy binaries. And
we can finally get rid of x11-libs/motif-config then.

We already have several *-compat packages in the tree, so this will not be an
exception.

Created an attachment (id=145984) [details]
Ebuild for legacy Open Motif 2.2 libraries

This contains an updated SRC_URI and a minor tweak in the sed expressions.

(In reply to comment #29)
> Created an attachment (id=145984) [edit] [details]
> Ebuild for legacy Open Motif 2.2 libraries

I can confirm this ebuild works beautifully on my system.  (using Maple 11)

(In reply to comment #30)
> I can confirm this ebuild works beautifully on my system.

Committed to tree as x11-libs/openmotif-compat-2.2.3.
Let's hope that everyone is happy now. ;-)

> Committed to tree as x11-libs/openmotif-compat-2.2.3.

I pruned the keywords to "~amd64 ~x86". Others will be added on users' request.

Closing.