Bug 203274

Summary: Review Request: lesstif - OSF/Motif(R) library clone
Product: [Fedora] Fedora Reporter: Patrice Dumas <pertusus>
Component: Package ReviewAssignee: Rex Dieter <rdieter>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Package Reviews List <fedora-package-review>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: dominik, eric-bugs, lemenkov, tcallawa
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-08-30 19:16:19 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 203993    
Bug Blocks: 163779    

Description Patrice Dumas 2006-08-20 10:38:16 UTC
Spec URL: http://www.environnement.ens.fr/perso/dumas/fc-srpms/lesstif.spec
SRPM URL: http://www.environnement.ens.fr/perso/dumas/fc-srpms/lesstif-0.95.0-1.src.rpm

Description: 
LessTif is a free replacement for OSF/Motif(R), which provides a full
set of widgets for application development (menus, text entry areas,
scrolling windows, etc.). LessTif is source compatible with
OSF/Motif(R).

Comment 1 Patrice Dumas 2006-08-20 10:52:33 UTC
lesstif is never abi compatible with openmotif. The soname
provided for the libraries is different than the one of the
current openmotif, and corresponds with earlier openmotif releases
(lesstif being abi incompatible with the openmotif library providing
those sonames). I don't know if it is correct or not nor what should 
be done.

I couldn't get the tests to work, since some bitmaps are missing,
which are in 
http://xorg.freedesktop.org/releases/individual/app/bitmap-1.0.2.tar.bz2
but don't seem to be in fedora extras or core (I reported that on
fedora-devel-list). I'll try to have the tests built, but I think it 
isn't that important.

I don't know if I did the right things with the 
obsolete/provides/conflicts. It is not obvious that lesstif should
obsolete openmotif, maybe only conflict. But in that case the 
buildrequires should be changed in all the packages depending on 
openmotif, and openmotif-devel will not be updated to lesstif-devel
on upgrades.

lesstif-devel really conflicts with openmotif-devel (same header and 
library names). And I think we should really avoid having openmotif
and lesstif libraries installed along since as I said above they are binary 
incompatible.

Comment 2 Paul F. Johnson 2006-08-20 10:56:49 UTC
Looking at the spec file...

Release: 1

Needs the dist tag

Are both of the obsoletes and provides required (yes, I've read the note about
the second one) for both the main package and in the devel package?

%package mwm
Does this not need requires %{name} = %{version}-%{release} as well?

What is lynx sucked into the BRs for?

Comment 3 Patrice Dumas 2006-08-20 11:07:43 UTC
(In reply to comment #2)
> Looking at the spec file...
> 
> Release: 1
> 
> Needs the dist tag

Right, missed it. I'll add it.

> Are both of the obsoletes and provides required (yes, I've read the note about
> the second one) for both the main package and in the devel package?

I don't know. I'm seeking advice on that matter.
 
> %package mwm
> Does this not need requires %{name} = %{version}-%{release} as well?

I don't think so, since I think it could be linked against
a binary compatible motif library. It may be safer, though.
I'll add it when I update the spec file.

> What is lynx sucked into the BRs for?

It is used to transform some html to text for the docs.

Comment 4 Patrice Dumas 2006-08-20 11:08:23 UTC
I didn't test an install of the lesstif packages
I propose, since they conflict with openmotif and there are 
apps (from fedora core and extras) I use that need openmotif, but I 
will test lesstif install (and rebuild the rpms) when the review
seems right.

Of course lesstif violates the guidelines because it conflicts
with a package in core, openmotif, but that's not unexpected...


Comment 5 Gianluca Sforna 2006-08-20 17:16:13 UTC
IIRC, lesstif used to be parallely installable with openmotif 2.x and it
provided compatibility with the older API (1.x) of Motif. 
Has this changed lately?

Comment 6 Patrice Dumas 2006-08-20 20:43:13 UTC
(In reply to comment #5)
> IIRC, lesstif used to be parallely installable with openmotif 2.x and it
> provided compatibility with the older API (1.x) of Motif. 
> Has this changed lately?

Indeed lesstif was only packaged for the 1.x compatibility
api (up to Fedora Core 3). But following the discussion 
initiated here:
https://www.redhat.com/archives/fedora-maintainers/2006-August/msg00076.html
I am now packaging it as an openmotif replacement. And there is
certainly no need for the 1.x api.

Comment 7 Patrice Dumas 2006-08-20 20:46:16 UTC
New version here, that builds in mock

http://www.environnement.ens.fr/perso/dumas/fc-srpms/lesstif-0.95.0-1.src.rpm

- BuildRequires automake for the shipped autoconf macro
- add %%dist in release
- tie mwm to the lesstif version and release


Comment 8 Ralf Corsepius 2006-08-21 03:55:28 UTC
(In reply to comment #6)

> I am now packaging it as an openmotif replacement.
FE package MUST NOT replace FC packages.

1. Unless openmotif is formally discontinued in Core, you MUST NOT do this.

2. Lesstif is not ABI compatible to OpenMotif, so you are breaking all Motif
based apps in FE, once this package should be released.

> And there is certainly no need for the 1.x api.
Who sais that?

1. There still exist tons of Motif-1.x SW.

2. The Motif-2.x API (==OpenMotif) has changed and extended many times. 
Lesstif hardly has any chance to follow up these changes, because it's a clone
and OpenMotif is the master.

Comment 9 Patrice Dumas 2006-08-21 07:13:06 UTC
(In reply to comment #8)
> (In reply to comment #6)
> 
> > I am now packaging it as an openmotif replacement.
> FE package MUST NOT replace FC packages.
> 
> 1. Unless openmotif is formally discontinued in Core, you MUST NOT do this.

That's the idea. openmotif shouldn't be in fedora since it is not
free software. It seems that you are reading that thread on 
fedora-maintainers, aren't you ;)

I don't plan on importing lesstif once it is approved, there must
be some agreement on how and when to proceed, if openmotif is really
to be replaced by lesstif.

> 2. Lesstif is not ABI compatible to OpenMotif, so you are breaking all Motif
> based apps in FE, once this package should be released.

Indeed, and that's bad, but unfortunately necessary to rely only
on free software.

> > And there is certainly no need for the 1.x api.
> Who sais that?

I don't have any idea on that matter, but I supposed so since it is 
not shipped since fedora core 3. Did anybody complain?
 
> 2. The Motif-2.x API (==OpenMotif) has changed and extended many times. 
> Lesstif hardly has any chance to follow up these changes, because it's a clone
> and OpenMotif is the master.

lesstif tries to follow the 2.1 api. Having a non free application 
providing more features is not a reason to ship it.

Comment 10 Gianluca Sforna 2006-08-21 11:15:15 UTC
(In reply to comment #6)
> Indeed lesstif was only packaged for the 1.x compatibility
> api (up to Fedora Core 3). But following the discussion 
> initiated here:
> https://www.redhat.com/archives/fedora-maintainers/2006-August/msg00076.html


Thanks for the pointer. I guess it's time for me to subscribe YAML... 

I have at work some legacy Motif apps: if you think it is useful I could try
rebuilding them against this new package.

Additionally, since in their FAQ [1] I can see:
Q: Will Motif be made Open Source in the future?
A: Yes, we hope to be able to make a distribution under a license complying with
the Open Source guidelines sometime in the future. For now this is as close as
to Open Source as we could get.

maybe we could try to bugging them for a real Open Source release, otherwise it
will be removed from Fedora ASAP


[1] http://www.opengroup.org/openmotif/faq.html

Comment 11 Rex Dieter 2006-08-21 11:54:32 UTC
Quick-n-dirty items I see:

1.  MUST drop Obsoletes/Provides: openmotif, openmotif-devel
at least for now(*).  No Conflicts either.  See also 6.

(*) Maybe we could consider using versioned Ob/Pr, say something like Obsoletes:
openmotif < 2.2, openmotif21, Provides: openmotif = 2.1, but there would have to
be a strong demonstratable need for this (and I currently don't see any). 

2.  MUST: +BuildRequires: fontconfig-devel, since ./configure says:
checking for fontconfig-config... no
checking fontconfig/fontconfig.h usability... yes
checking fontconfig/fontconfig.h presence... yes
checking for fontconfig/fontconfig.h... yes
checking for FcInit... yes

3.  MUST: +BuildRequires: mesa-libGLw-devel

4.  MUST: use versioned Obsoletes/Provides: lesstif-clients, ie,
Obsoletes: lesstif-clients < %{version}-%{release}
Provides:  lesstif-clients = %{version}-%{release}

5.  SHOULD: drop Oboletes/Provides: lesstif-1.2-devel, lesstif-2.0-devel
I see no purpose for this (anymore), especially Provides.

6.  SHOULD: Come up with a better co-installable solution, maybe split out
lesstif-clients again (like upstream) so the main pkg doesn't conflict.
Conflicts in -clients and/or -devel is ok, imo.  But for now, maybe don't worry
about this too much... we're going on the assumption (for now) that openmotif's
non-OSI license will eject it from Fedora.

Comment 12 Rex Dieter 2006-08-21 12:26:32 UTC
FYI, see also:
Bugzilla Bug #202527 รข openmotif's licensing is poor and it should be moved to
Fedora Extras

Comment 13 Patrice Dumas 2006-08-21 12:32:01 UTC
(In reply to comment #11)
> Quick-n-dirty items I see:
>
> 1.  MUST drop Obsoletes/Provides: openmotif, openmotif-devel
> at least for now(*).  No Conflicts either.  See also 6.

I will do that but don't we want to have mutually exclusive
packages, at least for -devel, with lesstif-devel replacing
openmotif-devel on upgrades?

> (*) Maybe we could consider using versioned Ob/Pr, say something like Obsoletes:
> openmotif < 2.2, openmotif21, Provides: openmotif = 2.1, but there would have to
> be a strong demonstratable need for this (and I currently don't see any).

I can't see how it would help either.

> 2.  MUST: +BuildRequires: fontconfig-devel, since ./configure says:
> checking for fontconfig-config... no
> checking fontconfig/fontconfig.h usability... yes
> checking fontconfig/fontconfig.h presence... yes
> checking for fontconfig/fontconfig.h... yes
> checking for FcInit... yes

Right, missed it.

> 3.  MUST: +BuildRequires: mesa-libGLw-devel

or libGLw-devel?

> 4.  MUST: use versioned Obsoletes/Provides: lesstif-clients, ie,
> Obsoletes: lesstif-clients < %{version}-%{release}
> Provides:  lesstif-clients = %{version}-%{release}

If you like.

> 5.  SHOULD: drop Oboletes/Provides: lesstif-1.2-devel, lesstif-2.0-devel
> I see no purpose for this (anymore), especially Provides.

I kept them from the fc3 spec. I'll remove.

> 6.  SHOULD: Come up with a better co-installable solution, maybe split out
> lesstif-clients again (like upstream) so the main pkg doesn't conflict.

I don't view it like this. If openmotif is going away, it would be
better to split openmotif to have a compat package that only provides
the binary libraries (with the issue of the sonames I report above
that could be very painfull).

If I haven't misunderstood what xmbind is, it should be provided with
the library, not in a separate package. And uil is, in y opinion much
better in the -devel subpackage.

> Conflicts in -clients and/or -devel is ok, imo.  But for now, maybe don't worry
> about this too much... we're going on the assumption (for now) that openmotif's
> non-OSI license will eject it from Fedora.

In any other case packaging lesstif to be fully parallel installable
would be too much pain without benefit, and may prove hard to achieve,
and using the lesstif library would be in that case quite painfull.


Comment 14 Rex Dieter 2006-08-21 12:44:54 UTC
>> 3.  MUST: +BuildRequires: mesa-libGLw-devel
>or libGLw-devel?

Right, better: BuildRequires: libGLw-devel

Comment 15 Patrice Dumas 2006-08-21 19:12:00 UTC
http://www.environnement.ens.fr/perso/dumas/fc-srpms/lesstif-0.95.0-3.src.rpm
- BuildRequires libGLw-devel
- remove openmotif Obsoletes/Provides
- add versioning to the Obsoletes/Provides for lesstif-clients


Comment 16 Patrice Dumas 2006-08-21 21:37:51 UTC
oops I forgot....

http://www.environnement.ens.fr/perso/dumas/fc-srpms/lesstif-0.95.0-4.src.rpm
- BuildRequires fontconfig-devel


Comment 17 Patrice Dumas 2006-08-21 21:41:51 UTC
(In reply to comment #10)
> (In reply to comment #6)

> I have at work some legacy Motif apps: if you think it is useful I could try
> rebuilding them against this new package.

Indeed it would be usefull (but wait until it is certain that lesstif 
will replace openmotif...). Are these 1.x or 2.x motif apps?

> Additionally, since in their FAQ [1] I can see:
> Q: Will Motif be made Open Source in the future?
> A: Yes, we hope to be able to make a distribution under a license complying with
> the Open Source guidelines sometime in the future. For now this is as close as
> to Open Source as we could get.
> 
> maybe we could try to bugging them for a real Open Source release, otherwise it
> will be removed from Fedora ASAP

That would be a good idea, but I won't do that. I don't feel 
speaking in the name of fedora.

Comment 18 Rex Dieter 2006-08-22 20:32:44 UTC
OK, now what to do with (potential) Conflicts: openmotif ?
<braindump>
1.  What left in the main/core pkgs conflict (lesstif vs openmotif)?  xmbind? 
We may want to split that out into -clients again to avoid that problem (for now).

2. -devel: the -devel pkgs conflict (right?), and that's allowable (imo), so
having a
Conflicts: openmotif-devel
isn't unreasonable

3.  Since openmotif's status is still not 100% certain, we could do something
funky like adding a virtual Provides for motif and motif-devel (and if openmotif
ever clears up it's status, it could add these too), so only could add something
like (to main):
Provides: motif = 2.1
and to -devel
Provides: motif-devel = 2.1
(the 2.1 is based on what version of the motif api it provides).
</braindump>

Comment 19 Patrice Dumas 2006-08-22 21:27:19 UTC
(In reply to comment #18)
> OK, now what to do with (potential) Conflicts: openmotif ?
> <braindump>
> 1.  What left in the main/core pkgs conflict (lesstif vs openmotif)?  xmbind? 
> We may want to split that out into -clients again to avoid that problem (for now).

I really feel uneasy about xmbind not being with the libraries, but
if it helps, no problem. An alternative would be to rename one of the
xmbind program (likely for the init script and the man page) to 
lesstif-xmbind or openmotif-xmbind.

> 2. -devel: the -devel pkgs conflict (right?), and that's allowable (imo), so
> having a
> Conflicts: openmotif-devel
> isn't unreasonable

Yep, this seems unavoidable. And, I beleive, right!

> 3.  Since openmotif's status is still not 100% certain, we could do something
> funky like adding a virtual Provides for motif and motif-devel (and if openmotif
> ever clears up it's status, it could add these too), so only could add something
> like (to main):
> Provides: motif = 2.1
> and to -devel
> Provides: motif-devel = 2.1
> (the 2.1 is based on what version of the motif api it provides).

For -devel that would be nice, but for main I think it would be
wrong since there is no ABI compatibility.

In fact there should even be a way to make package compiled
against lesstif require lesstif and for packages compiled 
against openmotif require openmotif. Indeed the usual way
to have library dependencies (using soname) doesn't work
well here, as the same soname is associated with binary 
incompatible libraries. Having a simple

Requires: openmotif
or 
Requires: lesstif

should be enough, since the dynamical linker may get it wrong
as they have the same soname, but then the library names 
would be the same and they would conflict. 

As long as the lesstif soname (and library name) differs from 
the openmotif soname this could be enough.

Does this seems right?

Comment 20 Patrice Dumas 2006-08-22 21:29:10 UTC
About the 1.x api, should it be shipped? I think not, since
it hasn't been shipped for FC4 and FC5 (and I guess FC6) but 
opinions may vary.

Comment 21 Dominik 'Rathann' Mierzejewski 2006-08-22 21:36:10 UTC
RPM build errors:
    Installed (but unpackaged) file(s) found:
   /usr/lib/libDtPrint.la
   /usr/lib/libDtPrint.so
   /usr/lib/libDtPrint.so.1
   /usr/lib/libDtPrint.so.1.0.0


Comment 22 Patrice Dumas 2006-08-22 21:41:45 UTC
(In reply to comment #21)
> RPM build errors:
>     Installed (but unpackaged) file(s) found:
>    /usr/lib/libDtPrint.la
>    /usr/lib/libDtPrint.so
>    /usr/lib/libDtPrint.so.1
>    /usr/lib/libDtPrint.so.1.0.0

That's very weird... There is, in %install

rm -f $RPM_BUILD_ROOT%{_libdir}/*.la

and the appropriate globs in %files:
%{_libdir}/lib*.so.*

and in devel
%{_libdir}/lib*.so

Could you please attach the build log?

Comment 23 Gianluca Sforna 2006-08-22 21:50:44 UTC
(In reply to comment #17)
> 
> Indeed it would be usefull (but wait until it is certain that lesstif 
> will replace openmotif...). Are these 1.x or 2.x motif apps?
Ok, I will wait for this. They are 2.x

> > 
> > maybe we could try to bugging them for a real Open Source release, otherwise it
> > will be removed from Fedora ASAP
> 
> That would be a good idea, but I won't do that. I don't feel 
> speaking in the name of fedora.

Well, it should be just a warning to them that something will happen here if
they do not act upon. I will try to get some more info and let you know

Comment 24 Dominik 'Rathann' Mierzejewski 2006-08-22 22:11:47 UTC
(In reply to comment #22)

Not necessary. This is an x86_64 issue. Apply the following patch:
--- lesstif-0.95.0/clients/Motif-2.1/mwm/Makefile.am.lib64      2005-03-26
07:52:24.000000000 +0100
+++ lesstif-0.95.0/clients/Motif-2.1/mwm/Makefile.am    2006-08-23
00:06:59.000000000 +0200
@@ -37,7 +37,7 @@

 appdir=                $(libdir)/X11/app-defaults

-mwmddir=       $(libdir)/X11/mwm
+mwmddir=       $(sysconfdir)/mwm
 mwmd_DATA=     system.mwmrc alt.map README


--- lesstif-0.95.0/lib/Dt/Makefile.am.lib64     2005-03-26 07:52:25.000000000 +0100
+++ lesstif-0.95.0/lib/Dt/Makefile.am   2006-08-22 23:56:46.000000000 +0200
@@ -5,7 +5,7 @@
 MAINTAINERCLEANFILES=Makefile.in

 libDtPrint_la_LDFLAGS= -version-info 1:0 -no-undefined
-libdir = $(exec_prefix)/lib
+#libdir = $(exec_prefix)/lib

 if BuildLibDtPrint

and regenerate auto* files before %configure:
%{__libtoolize} --force
%{__aclocal}
%{__autoconf}
%{__autoheader}
%{__automake} -a

For some reason, Dt includes don't get installed after that.

Also, don't use hardcodec paths like /usr/lib or /usr/include. That's what
%{_libdir} and %{_includedir} are for.


Comment 25 Patrice Dumas 2006-08-22 23:04:59 UTC
A new version
http://www.environnement.ens.fr/perso/dumas/fc-srpms/lesstif-0.95.0-5.src.rpm
- fix in Dt for x86_64, adapted Dominik patch
- don't hardcode /usr/include and /usr/lib
- add a Conflict for openmotif-devel

Dominik, i modified your patch such that there is no need to
rerun autoconf, could you please test?


Comment 26 Dominik 'Rathann' Mierzejewski 2006-08-23 00:07:17 UTC
Builds cleanly now, but please use proper English in the changelog and say
"Dominik's patch". ;)

As for the patch itself, I'd remove the commented line from it, i.e.:
-libdir = $(exec_prefix)/lib
+libdir = @libdir@


Comment 27 Gianluca Sforna 2006-08-24 07:58:25 UTC
(In reply to comment #23)
> 
> Well, it should be just a warning to them that something will happen here if
> they do not act upon. I will try to get some more info and let you know

For those interested, discussion going on here:

http://www.motifzone.net/forum/viewtopic.php?p=3883


Comment 28 Patrice Dumas 2006-08-24 21:24:32 UTC
I have filled Bug #203993 against openmotif to have parallel
installable openmotif and lesstif, and set it to block that 
bug.

Comment 29 Rex Dieter 2006-08-30 15:26:34 UTC
FYI, I'd like to make an announcement soon regarding openmotif's departure, so
please make the temporary adjustment here to lesstif to make it parallel
installable with openmotif(as-is), so, per comment #19,
>  An alternative would be to rename one of the
> xmbind program (likely for the init script and the man page) to 
> lesstif-xmbind or openmotif-xmbind.

I'd say use xmbind.lesstif and go with that (and then I'll FE-APPROVE this)

If/when openmotif goes away, the file renames can be reverted.

Comment 30 Patrice Dumas 2006-08-30 16:08:27 UTC
I changed my mind and put uil and xmbind in a lesstif-clients package, 
like upstream. That way it will be easier to have a -devel package 
parallel installable for different arches.

- split out a clients package that contains xmbind and uil

Should appear soon on 
http://www.environnement.ens.fr/perso/dumas/fc-srpms/lesstif-0.95.0-6.src.rpm

Comment 31 Rex Dieter 2006-08-30 16:20:16 UTC
excellent, APPROVED.

Comment 32 Patrice Dumas 2006-08-30 16:36:02 UTC
I have posted a new version:

- add a patch such that motif-config honors libdir

http://www.environnement.ens.fr/perso/dumas/fc-srpms/lesstif-0.95.0-7.src.rpm

Should I import that version in cvs as usual, even though it
conflicts with openmotif?

Comment 33 Rex Dieter 2006-08-30 16:58:54 UTC
> Should I import that version in cvs as usual, even though it
> conflicts with openmotif

I thought we cleared up all the conflicting bits (in the main/core pkgs anyway).

Comment 34 Patrice Dumas 2006-08-30 19:16:19 UTC
Built, added in owners.list.

Comment 35 Tom "spot" Callaway 2006-08-30 19:21:28 UTC
There are a few more things that this package needs before it should be committed:

- One of the headers needs to be fixed, or xpdf/ddd won't compile
- There are some obvious x86_64 cleanups that can be made
- We need to patch for CAN-2005-0605
- nuke host.def, imake owns that
- resolve rpmlint error from rpm-braindead behavior on handling symlinks with
debuginfo

I took your package and fixed all of those items:

http://www.auroralinux.org/people/spot/review/MOTIF/lesstif-0.95.0-8.src.rpm

Comment 36 Patrice Dumas 2006-08-30 21:24:50 UTC
Included and rebuilt