Need some advice on best packaging practices for a tricky package?

[Kevin Kofler]

David Howells wrote:
>  (1) As each set of cross-binutils manual pages is the same as every other
>  set
>      (and the core set come to that), I've stuffed the base manual pages
>      in their own RPM and put symlinks to them from the individual arch
>      RPMs.
> 
>      However, this results in lots of "dangling-relative-symlink"
>      warnings, even though the targets are in another RPM passed to
>      rpmlint.
> 
>      Can I make rpmlint ignore these?

Just ignore rpmlint there. :-) If you have proper Requires in place to 
ensure the symlink targets will actually be installed, it's fine.

>  (2) The manual pages and translation files RPM gets the warning
>  "no-binary" -
>      which is true.
> 
>      Is there any way to make the spec file produce a noarch RPM at the
>      same time as a bunch of binary RPMs?

Yes, it's called noarch subpackages and has been supported in Fedora for a 
while. Just declare the subpackage as:
BuildArch: noarch

Note that the main package MUST be arch-specific if you have any arch-
specific subpackages, you cannot have arch-specific subpackages of a noarch 
package, only noarch subpackages of an arch-specific package.

>  (3) The binutils installation installs some hard links and these cause
>  rpmlint
>      to issue "cross-directory-hard-link" warnings.  For instance the
>      following are hardlinked together:
> 
> /usr/cross/alpha-linux-gnu/bin/ar
> /usr/bin/alpha-linux-gnu-ar
> 
>      Should I manually turn the hardlinked variants into copies?  Or
>      symlink between them?

There too I think you can ignore rpmlint's warning.

>  (4) The binutils installer would like to create /usr/<target>/.  I'm
>  creating
>      /usr/cross/<target>/ to group all the stuff together into one dir
>      under
>      /usr.  However, rpmlint likes neither of these and gives a
>      "non-standard-dir-in-usr" warning.
> 
>      Should I put the stuff somewhere else?  /usr/lib/ or /usr/libexec/
>      perhaps?  I've tried to persuade the cross-gcc to use the things in
>      /usr/bin/, but it really doesn't want to do that.

/usr/<target> is the standard location for cross toolchains, and cross 
toolchains (and ONLY cross toolchains) are allowed to use such a location 
(though IIRC it never got officially codified in our guidelines because the 
cross-compiler guidelines never got formalized; but de facto, the existing 
cross compiler packages already use this).

/usr/cross/<target> is entirely non-standard and IMHO a bad idea.

>  (5) The binutils installer creates a supplementary "<target>-ld.bfd"
>  that's a
>      hardlink to "<target>-ld".  It doesn't, however, supply a manual page
>      for this.
> 
>      Is there a way to tell rpmlint that this is correct?  Or should I
>      just
>      discard the ld.bfd entirely?  What is it for, anyway?  I could even
>      link the manual page, I suppose.

There is no requirement that binaries have manpages in Fedora. Though in 
this case, just link the manpage.

The purpose of ld.bfd is that this is always the regular BFD-based GNU ld 
whereas just ld can be e.g. gold.

> And for cross-gcc:
> 
>  (6) I see "devel-file-in-non-devel-package" warnings for bits of gcc's
>      internal workings (such as libgcc.a).  These are required by gcc to
>      be able to work at all, so can't sensibly be split into a separate
>      package.
> 
>      Is there a way to tell rpmlint that these belong here?

Again, ignore rpmlint. Compilers are explicitly allowed to ship devel files.

>  (7) The common manpage and translation RPM triggers a "no-binary" warning
>  as
>      for cross-binutils.

See (2).

>  (8) The package installs gpl.7.gz and similar common-looking manpages in
>  man7.
>      Is this a bad idea, just in case there's a conflict with another
>      package wanting to do the same?

Yes. Don't package this. We don't normally ship licenses as manpages. See 
the next paragraph for what to do instead.

>      Is there/ should there be a common GPL licence text RPM with these
>      files in it that RPMs can be made dependent on?

Ship the license with %doc COPYING, in a package which is required by all 
the other subpackages. (If given only a file name without a path, %doc 
automatically creates a unique path for the package to ship the text file 
in.) For legal reasons, every package MUST carry its license in at least one 
subpackage, and ALL subpackages must either carry the license or Require one 
of the subpackages which do. A common license package for the whole 
distribution (like Debian does it) does NOT comply with the GPL. The 
packages are not necessarily distributed as part of the distribution, and 
the GPL explicitly requires every GPLed package to carry a copy of the GPL, 
no matter whether the distribution already has one.


In short, there's no requirement that you have zero rpmlint output, and it's 
normal that you have some bogus complaints for a cross-compilation 
toolchain, which is always a special case. But as I mentioned above, there 
are a few things you need to fix.

        Kevin Kofler