.gz suffix of compressed man pages in spec files
by Martin Gieseking
Hi,
during the review process of gtrayicon
(https://bugzilla.redhat.com/show_bug.cgi?id=524605) the question was
raised whether or not the .gz suffix of compressed manual pages should
be omitted in a spec file.
Since rpm automatically compresses man pages in a transparent process, I
prefer to avoid appending the explicit suffix and use asterisks instead.
On the other hand, adding .gz doesn't hurt as long as the compression
method stays unchanged.
So my question is: Is it up to the packager to either use
%{_mandir}/man1/foo.1.gz or %{_mandir}/man1/foo.1*? I couldn't find any
recommendation on this in the Fedora guidelines.
Regards,
Martin
14 years, 6 months
%doc removal behavior
by Braden McDaniel
I'm trying to move some API docs to a -doc subpackage. I'd like to
install these docs to /usr/share/doc/%{name}-%{version} (which
corresponds to where "make install" puts them); so I do
%files doc
%doc %{_docdir}/%{name}-%{version}/manual
instead of
%files doc
%doc doc/manual
However, I'd like to leave README and similar in the main package, where
I have
%files
%doc README NEWS COPYING.LESSER
The problem I'm running into is that in the course of packaging the docs
for the main package, rpm does
rm -rf %{_docdir}/%{name}-%{version}
So, when it subsequently tries to package the docs for the -doc
subpackage, the "manual" subdirectory (that was put there by "make
install") has been blown away.
What can I do here? Is it possible to suppress the "rm -rf" that %doc
does?
--
Braden McDaniel <braden(a)endoframe.com>
14 years, 6 months
Is md5sum compulsion in review instead sha1sum?
by Parag Nemade
Hi all,
I want to know that is there really any compulsion on posting
md5sum instead sha1sum? Review Guidelines said "Reviewers should use
md5sum for this task." I have started posting sha1sum for source in
package review.
Regards,
Parag.
14 years, 6 months
Unsponsored Comaintainer?
by Rich Mattes
Hello,
I'm new the packaging thing. I've been reading through all the rules
and guidelines, and preparing some new packages to submit. I was
wondering if it's possible to become a co-maintainer on an existing
package if you're still unsponsored. I've spoken to the current owner
of the package and he's more than happy to have me help out, but I don't
know if I have to submit my own package for review and become sponsored
first.
Thanks,
Rich Mattes
14 years, 6 months
Ocaml sub-package issue
by Orion Poplawski
I package plplot which ships bindings for oodles of languages, among
them perl and ocaml. The ocaml packaging guidelines suggest:
%global _use_internal_dependency_generator 0
%global __find_requires /usr/lib/rpm/ocaml-find-requires.sh
%global __find_provides /usr/lib/rpm/ocaml-find-provides.sh
to add the required ocaml Requires/Provides. However, this breaks the
automatic perl (and other?) generation for the perl sub-package.
How should this be handled? Is there a way to add the
ocaml-find-requires/provides to the normal list of providers? Shouldn't
this be done automatically by the build system?
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
14 years, 6 months
Small change to Beware of RPath
by Toshio Kuratomi
fabiand on IRC let me know that there's a minor change that could be
made to the Beware of RPath section of the Guidelines to make things
easier for packagers:
[10:23:07] <fabiand> regarding an wiki page i can not edit:
packaging:guidelines#beware_of_rpath
[10:23:57] <fabiand> it should be recommended to use %{_arch} not using
32 or 64 as a suffix for files in /etc/ld.so.conf, because it is easy to
use %{a_arch} but not easy to get 64 or 32
https://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath
It would change this:
{{{
If you are storing a library in a non-standard location (e.g.
/usr/lib/foo/), you should include a custom config file in
/etc/ld.so.conf.d/. For example, if I was putting 32 bit libraries of
libfoo in /usr/lib/foo, I would want to make a file called "foo32.conf"
in /etc/ld.so.conf.d/, which contained the following:
/usr/lib/foo
Make sure that you also make a 64bit version of this file (e.g.
foo64.conf) as well (unless the package is disabled for 64bit
architectures, of course).
}}}
To this::
{{{
If you are storing a library in a non-standard location (e.g.
%{_libdir}/foo/), you should include a custom config file in
/etc/ld.so.conf.d/. For example, if I was putting 32 bit libraries of
libfoo in /usr/lib/foo and 64 bit libraries in /usr/lib64/foo I would
want to make a file called "foo%{_arch}.conf" in /etc/ld.so.conf.d/,
which contained the following on 32 bit:
/usr/lib/foo
and on 64 bit:
/usr/lib64/foo
That could be done in the specfile with
echo %{_libdir}/foo >
%{buildroot}%{_sysconfdir}/ld.so.conf.d/foo%{_arch}.conf
}}}
If this looks like a good change I'll put it on the agenda for the next
meeting.
-Toshio
14 years, 6 months
Static-only library: clarification
by Michel Alexandre Salim
I'm currently reviewing a request for Telepathy-Qt4, which currently
only provides a static library:
https://bugzilla.redhat.com/show_bug.cgi?id=520663
It seems to me there are two different options:
- rename package to telepathy-qt4-static -- might cause administrative
hassle if and when upstream enables dynamically-linked libraries
- keep it as before, and just leave the main package empty. Make
-devel virtually Provides: -static.
Should the -doc subpackage depend on -devel? Should it be called
-devel-doc or -static-doc, or just -doc?
Thanks,
--
Michel Alexandre Salim
14 years, 6 months
