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).
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.
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?
(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.
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...
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?
(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.
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
(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.
(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.
(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
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.
FYI, see also: Bugzilla Bug #202527 รข openmotif's licensing is poor and it should be moved to Fedora Extras
(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.
>> 3. MUST: +BuildRequires: mesa-libGLw-devel >or libGLw-devel? Right, better: BuildRequires: libGLw-devel
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
oops I forgot.... http://www.environnement.ens.fr/perso/dumas/fc-srpms/lesstif-0.95.0-4.src.rpm - BuildRequires fontconfig-devel
(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.
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>
(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?
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.
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
(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?
(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
(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.
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?
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@
(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
I have filled Bug #203993 against openmotif to have parallel installable openmotif and lesstif, and set it to block that bug.
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.
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
excellent, APPROVED.
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?
> 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).
Built, added in owners.list.
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
Included and rebuilt