Bug 870049

Why do we need to enable static libraries?

%defattr(-,root,root) should be removed - it's no longer needed.

We have had static libs in the package for RHEL since years, it might be used.

(In reply to comment #3)
> We have had static libs in the package for RHEL since years, it might be
> used.

A very weak reasoning because there are bugs/issues in RHEL which are not fixed for years. Maybe this is exactly that case.

Anyway if you absolutely certain that we need static libs (I'm pretty sure we don't) you must pack them separately.

* https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries

O.k. new package is in place: 

- new sub package for static libraries
- added /etc/X11/mwm directory
- removed defattrs

BTW: rpmlint is complaining on tags in man pages (warnings).

Successful Koji scratchbuild for Rawhide:

* http://koji.fedoraproject.org/koji/taskinfo?taskID=4626409

REVIEW:

Legend: + = PASSED, - = FAILED, 0 = Not Applicable

+ rpmlint is NOT silent (1290 warnings!) but almost all of these warnings are about undefined macros in man-pages which isn't that harmful. You should take a look at them and report upstream. The rest of rpmlint messages are listed below:

Auriga ~: rpmlint Desktop/motif-* | grep -v manual-page-warning
motif.src: W: spelling-error %description -l en_US mwm -> mm, mam, mom

^^^ false positive.

motif.x86_64: W: shared-lib-calls-exit /usr/lib64/libUil.so.4.0.4 exit.5

^^^ that's a bad architectural design but it's not a blocker.

motif-static.x86_64: W: no-documentation

^^^ It's not required here. 

5 packages and 0 specfiles checked; 0 errors, 1290 warnings.
Auriga ~: 

+ The package is named according to the  Package Naming Guidelines.
+ The spec file name matches the base package %{name}, in the format %{name}.spec.
+ The package meets the Packaging Guidelines.
+ The package is licensed with a Fedora approved license and meets the Licensing Guidelines.
+ The License field in the package spec file matches the actual license (LGPL v2 or later).
+ The file, containing the text of the license(s) for the package, is included in %doc.
+ The spec file is written in American English.
+ The spec file for the package is legible.
+ The sources used to build the package, match the upstream source, as provided in the spec URL.
+ The package successfully compiles and builds into binary rpms on at least one primary architecture. See  koji link above.
+ All build dependencies are listed in BuildRequires.
0 No need to handle locales.
+ The package stores shared library files in some of the dynamic linker's default paths, and it calls ldconfig in %post and %postun.
+ The package does NOT bundle copies of system libraries.
0 The package is not designed to be relocatable.
+ The package owns all directories that it creates.
+ The package does not list a file more than once in the spec file's %files listings.
+ Permissions on files are set properly.
+ The package has a %clean section, which contains rm -rf %{buildroot} (or $RPM_BUILD_ROOT).
+ The package consistently uses macros.
+ The package contains code, or permissible content.
0 No extremely large documentation files.
+ Anything, the package includes as %doc, does not affect the runtime of the application.
+ Header files are stored in a -devel package.
+ Static libraries are stored in a -static package.
0 No pkgconfig(.pc) files.
+ The library file(s) that end in .so (without suffix) is(are) stored in a -devel package.

- The -devel package MUST require the base package using a fully versioned dependency: Requires: %{name}%{?_isa} = %{version}-%{release}. Note the "%{?_isa}" macro.

+ The package does NOT contain any .la libtool archives.
0 Not a GUI application (which means that it doesn't add some userspace graphical utilities which requires *.desktop file).

- The package can not own files or directories already owned by other packages.  I really concerned about 

* xorg-x11-xbitmaps who is the owner of the /usr/include/X11/bitmaps/ directory
* xorg-x11-xinit, owner of the /etc/X11/xinit/xinitrc.d/

*If* these packages are picked up automatically by a dependency checker then it's ok. If not - you must add them as a Requires.

+ At the beginning of %install, the package runs rm -rf %{buildroot} (or $RPM_BUILD_ROOT).
+ All filenames in rpm packages are valid UTF-8.


Almost done. 


* Please, fix devel sub-package dependency (requires %{?_isa} macro).
* Ensure that xorg-x11-xbitmaps and xorg-x11-xinit are picked up automatically and inserted into dependency chain while installing Motif rpm. Otherwise please add them explicitly.

*** Bug 870215 has been marked as a duplicate of this bug. ***

Ok, new spec and package in place:

http://twoerner.fedorapeople.org/Motif/motif.spec
http://twoerner.fedorapeople.org/Motif/motif-2.3.4-2.fc17.src.rpm

(In reply to comment #9)
> Ok, new spec and package in place:
> 
> http://twoerner.fedorapeople.org/Motif/motif.spec
> http://twoerner.fedorapeople.org/Motif/motif-2.3.4-2.fc17.src.rpm

I can't find any other issues so this package is


APPROVED.

New Package SCM Request
=======================
Package Name: motif
Short Description: Run-time libraries and programs
Owners: twoerner siddharths
Branches: f17 f18
InitialCC:

Git done (by process-git-requests).

So what will you do with lesstif, will this package Obsolete it? Or is the plan to keep it as a compatibility package for the old OpenMotif 2.1 ABI (libXm.so.2)?

(In reply to comment #13)
> So what will you do with lesstif, will this package Obsolete it? Or is the
> plan to keep it as a compatibility package for the old OpenMotif 2.1 ABI
> (libXm.so.2)?

IIRC lesstif is targeting compatibility with motif 1.2 which should be libXm.so.2
motif 2.1 is libXm.so.4

saying that the motif package provide openmotif, how the path to
/usr/lib64/openmotif/libXm.so.4 should be interpreted ? ldconfig

motif is not obsoleting lesstif right now, but it should do this in the near future.

Even with this latest Motif version old code (version 1.x and up) still can be compiled and used.