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