"Explicit requires" and "requiring base package"
by Ville Skyttä
https://fedoraproject.org/wiki/Packaging/Guidelines#Explicit_Requires
Packages must not contain explicit Requires on libraries except when
absolutely necessary. [...]
https://fedoraproject.org/wiki/Packaging/Guidelines#Requiring_Base_Package
Devel packages must require the base package using a fully versioned
dependency: Requires: %{name} = %{version}-%{release}. Usually, subpackages
other than -devel should also require the base package using a fully
versioned dependency.
I think these two guidelines or their wording are more or less in conflict
these days. Most -devel packages do not "absolutely necessarily" need an
explicit dependency on the base package because rpm automatically adds soname
dependencies from symlinks in -devel to the corresponding shared lib in the
main/lib package. Ditto, many cases of other non-devel subpackages get
automatic lib soname dependencies to the main/lib package.
If the intent is to still require explicit deps like in "requiring base
package" even though there are automatic ones that would usually work, just to
be sure or for other reasons (possibility of compilation options, patchwork
that affects some internal subpackages but not other -devel/lib package
consumers), I think "requiring base packages" and "explicit requires" should
be cross referenced noting that this is an exception and those explicit deps
are indeed wanted.
If not, IMO "requiring base package" should be softened so that it requires
adding those explicit deps if no automatic ones are present, or just removed
because that'd be redundant with "explicit requires" and the rest of the
general dependency guidelines.
14 years
Generic filtering macros...
by Chris Weyl
So, I have a number of macros that taken together create a generic filtering
system for our autoprov/dep system.
http://fedorapeople.org/~cweyl/macros.perl.local
http://fedorapeople.org/~cweyl/macros.perl (suitable for ~/.rpmmacros
inclusion)
As this has a not insignificant amount to do with packaging, I'm looking for
some feedback both on the macros themselves as well as on the best approach
to get these included by default. (File a feature and get it approved?
File a bug against rpm? A small ritual sacrifice? :))
Thanks!
-Chris
--
Chris Weyl
Ex astris, scientia
14 years, 3 months
Phase out buildroot?
by Toshio Kuratomi
Since the rpm version shipped in Fedora 10 and beyond defines a default
buildroot, I think we can start phasing out the current buildroot
Guideline. How about adding this to the start of the buildroot tag section?
"""
=== Buildroot tag ===
{{{admon/note|The RPM in Fedora 10 defines a default buildroot so in
Fedora 10 and above it is no longer necessary to define a buildroot tag.
Fedora < 10 and EPEL 5 or less still need to have the tag.}}}
[Current content remains until EPEL-5 is no longer maintained]
"""
https://fedoraproject.org/wiki/Phase_out_buildroot_tag_%28draft%29
-Toshio
14 years, 4 months
redmine package review
by jan.klepek
Hi,
I'm working on unofficial package review for redmine
( https://bugzilla.redhat.com/show_bug.cgi?id=499959 ).
Redmine is written in ruby and is using rubygem-actionwebservice, which
is shipped with redmine.
Rubygem-actionwebservice was abandoned by upstream like two years ago,
and same happened for fedora package. My question is if redmine package
should install it on system or it should be considered as blocker, until
upstream of redmine migrate to activeresource.
Second question is when redmine contains plugins which are separate
applications/libraries (coderay is used by redmine for example) this
applications/libraries should be shipped within this package or should
be shipped in it's own package (and package should be created when it
doesn't exists)? My thoughts are that it should be shipped separately,
so it could be used by more applications.
Thanks for help,
Jan Klepek
14 years, 4 months
Requiring xinetd when placing files into /etc/xinetd.d
by Todd Zullinger
A conversation¹ on fedora-list reminded me of something I found a while
back and never got around to asking about...
It seems that about half of the packages that place files in
/etc/xinetd.d require xinetd and half do not:
$ repoquery --qf '%{name}' --whatprovides '/etc/xinetd.d/*' | \
sort -u | while read p; do
repoquery --requires $p | \
grep -q xinet && echo "$p: YES" || echo "$p: NO"
done
amanda: YES
apg: NO
authd: YES
bitlbee: YES
cups-lpd: YES
cvs: NO
ebhttpd: NO
ebnetd: NO
finger-server: YES
git-daemon: NO
krb5-workstation-servers: YES
ldminfod: NO
leafnode: YES
libident-tools: NO
ltsp-server: NO
ndtpd: NO
node: YES
nuttcp: NO
proftpd: NO
pure-ftpd: NO
rsh-server: YES
rsync: NO
samba-swat: YES
talk-server: YES
telnet-server: YES
tftp-server: YES
uucp: NO
uw-imap: YES
vnc-ltsp-config: YES
vtun: YES
xinetd: YES
I am sure there are a few valid reasons a package might place files
into /etc/xinetd.d and not require xinetd, such as cvs or rsync, which
both provide plenty of functionality without xinetd.
A package like git-daemon on the other hand, which is a subpackage
specifically designed to provide an xinetd service, really ought to
require xinetd to give a good experience out of the box, correct?
While it is possible to setup an init script to run git-daemon²,
that's not how we ship it in the current packages. (I'm one of the git
co-maintainers, and I'm leaning toward adding an xinetd requirement,
unless I learn of good reasons not to do so. I'm slightly torn
because adding an xinetd requirement may well annoy some folks that
prefer to setup an init script.)
I'm guessing that /etc/xinetd.d being provided by the filesystem
package is designed to allow for cases like cvs and rsync, but that
happened back in 2000, and the filesystem spec file doesn't leave any
bugzilla breadcrumbs to follow to see what other reasons there might
be for not requiring xinetd.
If anyone has pointers that might help illustrate other cases where
not requiring xinetd is the best course, I'd be glad to know about
them. At the same time, if anyone is familiar with the packages in
the "NO" category above, giving a closer look to whether any of them
really should be requiring xinetd would probably be a good idea.
¹ http://www.redhat.com/archives/fedora-list/2009-May/msg01664.html
² https://bugzilla.redhat.com/480755
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Reason obeys itself; and ignorance does whatever is dictated to it.
-- Thomas Paine
14 years, 4 months
"file listed twice" warning
by Daniel Novotny
hello,
I am now fixing stuff in a package for a merge review and this include getting rid of "file listed twice" warnings
the situation is this:
%files
%{mmdir}/Mailman
# ...
%attr(0644, root, %{mmgroup}) %config(noreplace) %verify(not md5 size mtime) %{mmdir}/Mailman/mm_cfg.py
so there's a directory, with lots of sub-directories and files, I want all of them included,
but one file of those needs special permissions, directives and such:
after that, rpmbuild tells me it's listed twice: once in the directory and once in the "%config", "%attr" definition
is there a way around this? probably a directive "I know the file is already listed, just want to change the flags"
-Daniel Novotny
14 years, 4 months
Correction to guidelines on %define vs %global
by Panu Matilainen
Apologies for missing this when the recommendation of %global over %define
in Fedora guidelines was being discussed, but better late than never...
https://fedoraproject.org/wiki/Packaging/Guidelines#.25global_preferred_o...
says "The two macro defining statements behave the same when they are a
the top level of rpm's nesting level" but this is not correct:
The body of a %global macro is expanded at definition time, whereas the
body of a %define is expanded only when used. For many uses it doesn't
make any difference but identical they are not, even on top level - for
example see the attached example spec:
$ rpmbuild -bp macroex.spec 2>/dev/null|grep ^case
case1: first - second
case2: second - %{xxx}
Another example of this difference (in case of parametrized macros):
https://bugzilla.redhat.com/show_bug.cgi?id=495658
- Panu -
14 years, 4 months
Use of macros for standard commands & wishlist of helper programs
by Susi Lehtola
Hi,
First: should we have a policy of using macros for standard commands?
RPM includes standard macros such as %{__mv}, %{__rm}, %{__mkdir},
%{__cp}, %{__python}, %{__perl} and so on, which are used by some
people.
I find that the use of these macros unnecessarily obscures the spec file
and thus would like to have the ban on these as part of the Packaging
Guidelines.
Second, a packager's / reviewer's software wishlist:
- Is there some tool to check out the redundancy of Requires and
BuildRequires? If not, it should be quite trivial to code, since all the
tool would need to do is pull the full requirement tree for each R and
BR and crosscheck whether there is overlap.
Of course, I would do this myself but I'm not as familiar as I should be
with a) python, b) yum bindings or c) GUI programming to code such a
thing.
- Also a some kind of review helper tool would be nice. This should have
preferably (skeleton) input files in text for different types of
reviews: C libraries, python modules etc could all have a customized
review checklist.
The tool would then present the GUI checklist formed from the skeleton
input file, with a tab of possible resolutions (e.g. OK, NEEDSWORK,
N/A, ?) and a comment text box for each item.
The output could be saved to a text file and pasted into the review in
BZ (or the tool could even have a direct connection with BZ?).
--
Jussi Lehtola
Fedora Project Contributor
jussilehtola(a)fedoraproject.org
14 years, 4 months
initddir vs initrddir
by Jochen Schmitt
Hallo,
on https://bugzilla.redhat.com/show_bug.cgi?id=501130 the submitter
of a review request has posted the following coment:
Well, /usr/lib/rpm/platform/i586-linux/macros from rpm-4.6+ shows following:
%_initddir %{_sysconfdir}/rc.d/init.d
# Deprecated misspelling
%_initrddir %{_initddir}
For clarification I want to ask for the current status of using
_initrddir versus
_initddir on the packaging guildelines.
Best Regards:
Jochen Schmitt
14 years, 4 months
