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 attachment 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 attachment 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 attachment 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 attachment 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] > 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.
