packaging May 2009

packaging@lists.fedoraproject.org

49 participants
29 discussions

"Explicit requires" and "requiring base package"
by Ville Skyttä 10 Sep '09

10 Sep '09

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.

2 5

Generic filtering macros...
by Chris Weyl 01 Jul '09

01 Jul '09

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

4 14

Phase out buildroot?
by Toshio Kuratomi 01 Jun '09

01 Jun '09

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

4 6

redmine package review
by jan.klepek 31 May '09

31 May '09

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

1 0

Requiring xinetd when placing files into /etc/xinetd.d
by Todd Zullinger 27 May '09

27 May '09

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

2 3

"file listed twice" warning
by Daniel Novotny 26 May '09

26 May '09

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

2 1

Correction to guidelines on %define vs %global
by Panu Matilainen 26 May '09

26 May '09

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_ove… 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 -

4 4

[Draft] The use of alternatives
by Dominik 'Rathann' Mierzejewski 25 May '09

25 May '09

Hi. The UsingAlternatives draft[1] should now be ready for voting at the next meeting. I've just made some finishing touches. I'd like to include it in the agenda for the next FPC meeting. Regards, R. [1] https://fedoraproject.org/wiki/PackagingDrafts/UsingAlternatives -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"

3 4

Use of macros for standard commands & wishlist of helper programs
by Susi Lehtola 21 May '09

21 May '09

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

5 4

initddir vs initrddir
by Jochen Schmitt 20 May '09

20 May '09

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

5 6

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging May 2009