This was promised to be fixed two times in the past, but all openmotif ebuilds (2.1 and 2.2, stable and unstable) are again (or still?) not installing essential files, namely * virtual bindings * motif bitmaps * mwm app-defaults
mwm app-defaults are installed by motif-config virtual bindings and bitmaps are currently not installed by motif-config because of license issues with lesstif
Sorry, that's not true. Motif-config may install something that looks like an app-defaults file, but wrong name so it's the same as no app-defaults file. Stable openmotif 2.1 does not use motif-config and installs no app-defaults file either. system.mwmrc is not found with all existing ebuilds. Please trust me if I go though the trouble of opening a bug report that there really is a bug. Second, what does motif-config have to do with virtual bindings and bitmaps? Stable ebuilds don't even use motif-config. Please clarify. Since when are there licensing issues with lesstif? All other known Linux distributions come with both sets of files and motif packagers of two of them I talked to never heard of such issues. Please clarify. URL? Third motif is an industrial strength toolkit that is expected to be complete in production environments. Please stop crippling it like that. Many thanks in advance.
First: I am only talking about the ~arch versions, the old versions are no longer supported and don't use motif-config as you might noticed First: What's the correct name of the app-defaults so I can fix it? Second: openmotif-2.2 and openmotif-2.1 both include the same bitmaps and bindings files thus leading to collisions when installed at the same time (which is possible with ~arch versions) so we have to move them out of the ebuilds into a shared ebuild, that is motif-config Third: If motif-config included the bitmaps and bindings from openmotif, lesstif cannot be installed without depending on openmotif files which then has license issues for people only wanting lesstif
still interested in this? If yes, please reopen with a patch :)
(In reply to comment #4) > still interested in this? If yes, please reopen with a patch :) The patch is to uncomment the commented-out stuff in the x11-libs/motif-config ebuild (or, better said, moving this to src_unpack instead of the horrible untar in src_install, and renaming and moving the tarballs to mirrors and out of ${FILESDIR} where they don't belong anyway).
Created attachment 140039 [details, diff] motif-config-0.10-r2.ebuild Sanitizes the thing as much as possible... :P
(In reply to comment #6) > Created an attachment (id=140039) [edit] > motif-config-0.10-r2.ebuild Shouldn't "clean up orphaned cruft" better go to pkg_preinst instead of pkg_setup? If there is some failure in src_{unpack,install} you don't want to modify the live system.
(In reply to comment #7) > Shouldn't "clean up orphaned cruft" better go to pkg_preinst instead of > pkg_setup? If there is some failure in src_{unpack,install} you don't want to > modify the live system. Shrug; everything that's left there after unmerging the blockers (you can't install this without doing that first) is useless orphaned cruft that shouldn't be there.
(In reply to comment #6) > Created an attachment (id=140039) [edit] > motif-config-0.10-r2.ebuild > > Sanitizes the thing as much as possible... :P Committed (with some minor modifications) as 0.10-r2.
lesstif depends on motif-config, but the dependencies of motif-config block out all versions of lesstif (in shiny new 0.10-r2, this breaks world updates that use lesstif) if motif-config is not needed for lesstif, then somebody should take out the dep there if it's needed/used then please correct the depspec of motif-config Best regards, cmuelle8
Intended; lesstif will be removed from the tree - unmerge it.
Why? When Gentoo is about choice and lesstif isn't dead (is it?) shouldn't it stay? If this is still relevant: http://www.gnu.org/philosophy/motif.html ..then there is a good point to keep that choice.. regards, cmuelle8
(In reply to comment #12) > Why? When Gentoo is about choice and lesstif isn't dead (is it?) shouldn't it > stay? See Bug 117057 Comment #17. One implementation of this legacy toolkit is more than enough, plus the current situation is completely FUBARed.
ok, thx for the pinpoint