August 2007 - packaging - Fedora mailing-lists

Tcl packaging guidelines proposal
by Michael Thomas 02 Jan '08

02 Jan '08

I sent this proposal to f-m-l about a week ago to gather comments, and there were no serious disagreements with the proposal which have not yet been addressed (thanks to Tibbs and Toshio for their feedback). Basically, I want to establish a set of guidelines for packaging Tcl extensions, as we already have guidelines for other popular scripting languages. In addition to making Tcl packages more consistent with each other, it will also help work toward fixing my pet-peeve bug (bz #226893) http://fedoraproject.org/wiki/PackagingDrafts/Tcl Please let me know if I need to do anything to help get these draft guidelines adopted. Thanks, --Wart

4 10

font package naming
by Jens-Ulrik Petersen 21 Sep '07

21 Sep '07

Hi, I would like to propose adding the following text to our "Package Naming Guidelines". http://fedoraproject.org/wiki/Packaging/NamingGuidelines ''' == Fonts Packages == Font packages should be named with the upstream name appended with `-fonts`. Examples: {{{ bitmap-fonts dejavu-lgc-fonts ghostscript-fonts urw-fonts xorg-x11-fonts }}} ''' Should the text discuss what to do when the upstream name contains the word "font" already? See https://www.redhat.com/archives/fedora-maintainers/2007-February/msg00794.h… and https://www.redhat.com/archives/fedora-maintainers/2007-March/msg00262.html for some recent discussion of <upstreamname>-fonts vs fonts-<language> and "-fonts" vs "-font" for singlet font packages. Comments or objections? Jens ps We might even consider renaming some of our "fonts-*" packages to follow this naming scheme for F8.

4 10

Packaging/ScriptletSnippets, fonts section: no "|| :" at the end of the fc-cache call?
by Thorsten Leemhuis 19 Sep '07

19 Sep '07

Hi all, the Fonts section on http://fedoraproject.org/wiki/Packaging/ScriptletSnippets contains this: > Use this when your package installs new fonts. > > {{{ > %post > if [ -x %{_bindir}/fc-cache ]; then > %{_bindir}/fc-cache %{_datadir}/fonts > fi > %postun > if [ "$1" = "0" ]; then > if [ -x %{_bindir}/fc-cache ]; then > %{_bindir}/fc-cache %{_datadir}/fonts > fi > fi > }}} Is there a specific reason why there is no "|| :" at the end of "%{_bindir}/fc-cache %{_datadir}/fonts"? I think there should be one, as this happened to me during a F-7 -> rawhide update (that's still in progress while I'm writing this mail, so more errors might show up): > Updating : bitstream-vera-fonts ################### [ 383/1850] > /usr/share/fonts/default/Type1: failed to write cache > /usr/share/fonts/default/ghostscript: failed to write cache > error: %post(bitstream-vera-fonts-1.10-8.noarch) scriptlet failed, exit status 2 [...] > Updating : fontconfig ################### [ 416/1850] > /usr/share/fonts/default/Type1: failed to write cache > /usr/share/fonts/default/ghostscript: failed to write cache > /usr/share/X11/fonts/Type1: failed to write cache > error: %post(fontconfig-2.4.2-5.fc8.x86_64) scriptlet failed, exit status 3 [...] > Updating : dejavu-lgc-fonts ################### [ 548/1850] > /usr/share/fonts/default/ghostscript: failed to write cache > error: %post(dejavu-lgc-fonts-2.19-1.noarch) scriptlet failed, exit status 1 > Updating : liberation-fonts ################### [ 549/1850] > /usr/share/fonts/default/ghostscript: failed to write cache > error: %post(liberation-fonts-0.2-1.fc8.noarch) scriptlet failed, exit status 1 CU knurd

5 5

Packaging Draft LSB Initscripts
by Harald Hoyer 06 Sep '07

06 Sep '07

Open for comments/corrections/modifications... http://fedoraproject.org/wiki/PackagingDrafts/SysVInitScript

5 6

kernel mod package howto?
by Neal Becker 31 Aug '07

31 Aug '07

I'm submitting blcr which builds a kernel mod. Where can I find info on packaging for kernel mods? Examples?

5 6

tex related packages names
by Patrice Dumas 31 Aug '07

31 Aug '07

Hello, I propose tex packages to be named tex-something instead of tetex-something I also think that it is not worth renaming existing packages with tetex-, at least for now, maybe later, but instead have them Provides: tex-something = %{version}-%{release} -- Pat

5 10

Zope Public License
by Paul Howarth 29 Aug '07

29 Aug '07

http://fedoraproject.org/wiki/Licensing lists two versions (1.0 and 2.0) of the Zope Public License in the "good licenses" list. Both entries in the table refer to http://www.zope.org/Resources/ZPL, which has contained the text of version 2.1 of the license for quite some time. Can ZPLv2.1 please be added to the good licenses list, as it's needed for python-zope-interface. Paul.

2 1

sendmail license
by Paul Howarth 29 Aug '07

29 Aug '07

The sendmail license (http://www.sendmail.org/ftp/LICENSE) is not currently listed in the "Good licenses" list, nor is it listed on the FSF "list of licenses" page. However, sendmail *is* listed in the FSF directory of free software (http://directory.fsf.org/sendmail.html) Please can the sendmail license be added to the good licenses page? Paul.

1 0

Python Egg Guidelines
by Toshio Kuratomi 28 Aug '07

28 Aug '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello all, I've finished a first draft of guidelines for using python eggs. There's one open question -- whether we should be creating eggs for upstreams that do not create them by default. I think the answer to that is no except for one special case but others might disagree. The rest of it is pretty straightforward; made longer by the addition of copious examples. Take a look and give feedback. The Packaging Committee will vote on this on Tuesday (next week's packaging meeting.) https://fedoraproject.org/wiki/PackagingDrafts/PythonEggs PS: We already have a couple of cases where we need to apply these guidelines * Review for parallel installable python-sqlalchemy0.3: https://bugzilla.redhat.com/show_bug.cgi?id=257381 * Request for python-cherrypy-3.0 upgrade which needs a python-cherrypy2 compat package for TurboGears. https://bugzilla.redhat.com/show_bug.cgi?id=224683 * Request to add egginfo to docutils (which is a departure from upstream). https://bugzilla.redhat.com/show_bug.cgi?id=256541 - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG1MfaX6yAic2E7kgRAmIlAJkBMOooviBZHGZhkg+Anh5kBQvDkACeIXLq poCNwcUzHDbE8DN8EHU+58g= =NZPE -----END PGP SIGNATURE-----

1 0

overview of all Package Guidelines or use CategoryPackageGuidelines
by Till Maas 28 Aug '07

28 Aug '07

Hi, is there a page in the wiki that simply lists all existing guidelines for packages in Fedora? I guess not. Therefore I suggest to add all these guidelines to CategoryPackageGuidelines. I cannot do this myself, because I cannot change the regarding wiki pages. Regards, Till

1 0

Wiki is inconsistent on Mono file locations
by Mary Ellen Foster 27 Aug '07

27 Aug '07

Disclaimer: I'm not a Mono programmer; I'm just trying to package something that includes some Mono pieces. I was looking at the Wiki about packaging for Mono (http://fedoraproject.org/wiki/Packaging/Mono) and it seems to contradict itself. Under "File locations", it says Mono packages should install assemblies to %{_libdir} rather than /usr/lib or %{_datadir} Then, right below, it gives sample gacutil lines that install into %{_prefix}/lib, with a note that it might later change to %{_libdir} and a link to a bug with a lot of discussion, but no clear indication of whether the proposal was accepted or not. So, should my stuff go into %{_libdir} or %{_prefix}/lib? Thanks very much! MEF -- Mary Ellen Foster http://homepages.inf.ed.ac.uk/mef/

2 2

commands under privileged users' path
by Mamoru Tasaka 24 Aug '07

24 Aug '07

Well, currently I am reviewing several reviewing requests and I asked a submitter to change user/group registration scriptlets according to http://fedoraproject.org/wiki/Packaging/UsersAndGroups and he/she changed as such. Then I noticed : %pre servers # Following the Wiki instructions ... getent group iceuser > /dev/null || groupadd -r iceuser <snip> Here "groupadd" (which is in Fedora under /usr/sbin) is used by only basename, not by full path. IMO this will cause a problem when "yum update" or "rpm -ivh" is done by normal users using "su -c" or "sudo" because normal users usually don't have /usr/sbin in their path. So I think that the following should be added to the wiki that commands which are under privileged users' path and not under normal users' path must be written with full path. Do you have any suggestions? Regards, Mamoru

2 2

Re: [Fedora-packaging] review guidelines vs packaging guidelines
by Nicolas Mailhot 23 Aug '07

23 Aug '07

Le Jeu 23 août 2007 12:58, Patrice Dumas a écrit : > Ok, I didn't understood it that way. But it isn't true, the guidelines > are setup such that having no ownership of a directory is impossible. I'm not so sure. The lax guidelines are more ambiguous, at no time do they clearly say "every directory must be owned" (with single or multiple owners). They say "the rule of thumb is everything must be owned but there are exceptions". And then proceed with some examples where every directory is accounted for without explicitely stating this is a hard rule. I don't think the OP would have been so happy with the lax version if he had understood them to enforce this rule. IMHO since the documented "exceptions" are clearly targetted at perl modules, it would be better to create a perl-filesystem package and forget about all the complex A/B convolutions in the guidelines. But that's for the perl SIG to discuss. -- Nicolas Mailhot

4 5

why not %{_datadir} on fonts scripletsnippet
by Jens-Ulrik Petersen 23 Aug '07

23 Aug '07

Hi, http://fedoraproject.org/wiki/Packaging/ScriptletSnippets#head-4863fc4c93ce… The "Fonts" scriptlets currently have: %{_bindir}/fc-cache /usr/share/fonts is there some subtle reason for not using %{_datadir} here? I'll for responses before changing it to: %{_bindir}/fc-cache %{_datadir}/fonts Jens -- Jens Petersen Internationalization Team Red Hat

4 8

Re: [Fedora-packaging] review guidelines vs packaging guidelines
by Nicolas Mailhot 23 Aug '07

23 Aug '07

Le Jeu 23 août 2007 11:52, Patrice Dumas a écrit : > It is not always worth creating a filesystem package for these cases. > Simply having more than one package own the directory is simpler, and > although not perfect, acceptable. When two packages share a directory sure it's not worth creating a separate package just for this directory. What I was suggesting was more like the games SIG collecting all the stray directories in a filesystem-games package, same for the perl SIG, etc Certainly there is a level at which you can create useful filesystem packages without falling in the whole-repository or single-directory package traps. That being said multiple ownership is compliant with the strict guidelines version, what I object to is no ownership as suggested by the lax variant. Regards, -- Nicolas Mailhot

2 1

review guidelines vs packaging guidelines
by Matthias Clasen 23 Aug '07

23 Aug '07

The review guidelines have this: - MUST: A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory. The exception to this are directories listed explicitly in the Filesystem Hierarchy Standard (http://www.pathname.com/fhs/pub/fhs-2.3.html) as it is safe to assume that those directories exist. The packaging guidelines say: The rule of thumb is that your package should own all of the directories it creates except those owned by packages which your package depends on. However, there are exceptions to this. If the directory hierarchy your package is located in may change due to updates of packages you depend on, then you need to take care to own those pieces of the hierarchy. [...] Another exception for directory ownership in packages is when there is no clear dependency hierarchy. I think the shortened version in the review guidelines is misleading and causes us to err on the side of adding unwanted dependencies just for directory ownership reasons. Can we have it changed to mention the furhter exceptions that are discussed in the packaging guidelines ?

3 2

Are circular dependencies ok?
by Stepan Kasal 22 Aug '07

22 Aug '07

Hello, in perl, circular dependencies are heavily used. First, "perl" and "perl-libs" require each other; this is a usual solution of the multilib problem, rpm{,-libs} and python{,-libs} are doing the same. Let's put this aside. Second, package "perl-devel" requires packages: perl-CPAN perl-ExtUtils-Embed perl-ExtUtils-MakeMaker perl-Test-Harness perl-Test-Simple all these packages require perl-devel, most of them by a direct requirement, only perl-CPAN by requiring perl-ExtUtils-Embed. I believe this is correct: - the modules have to have separate rpm, to match the real situation: they use a separate versioning scheme, for example. - perl-devel has to require them; these modules are required by scripts packed in perl-devel But this seems to bring problems, see the comments in https://admin.fedoraproject.org/updates/testing/F7/perl-5.8.8-22.fc7 Is this just a bug in yum, or is there a problem on my side? Thanks, Stepan Kasal

5 12

Packaging guidelines for Emacsen add-on packages
by Jonathan Underwood 15 Aug '07

15 Aug '07

Dear Packaging Committee, I have placed a draft Guidelines document on the wiki for your consideration. This document covers the packaging of Emacs and XEmacs add-on packages, and provides two template spec files with the intention of lowering the inertial barrier to developing packages for (X)Emacs. The doc can be found here: http://fedoraproject.org/wiki/PackagingDrafts/EmacsenAddOns And I have added it to the table here: http://fedoraproject.org/wiki/PackagingDrafts/DraftsTodo This document doesn't attempt to change guidelines in any way, but rather clarify the situation as presented in the Package Naming Guidelines, and codify them in the form of spec templates. Comments gladly received! Best wishes, Jonathan

7 49

Missing the meeting today
by Toshio Kuratomi 14 Aug '07

14 Aug '07

Sorry for the last minuteness of this, My sister's stuck at the airport so I'll be missing the meeting. -Toshio

1 0

Missing today's meeting
by Ralf Corsepius 14 Aug '07

14 Aug '07

Hi, due to sudden unplanned commitments, I'll not be able to attend today's FPC meeting. Ralf

1 0

Licensing guidelines suggestions
by Ville Skyttä 13 Aug '07

13 Aug '07

Hello, Here's a few notes/questions that IMO need to be addressed in the new licensing guidelines in Wiki. IANAL, etc, but anyway, something for near future FPC meetings (which I still probably won't be able to attend to for a couple of weeks): 1) The licensing pages strongly imply that OSI-approved licenses are ok. However for example the original Artistic license is OSI-approved but listed in Wiki page as "bad". Something needs real fixing - "ask upstream to move to a "good" Artistic license" is IMO just a band aid. http://fedoraproject.org/wiki/Licensing http://www.opensource.org/licenses/artistic-license.php 2) The Wiki pages refer to "files" and "content" without specifying whether those refer to files/content in the source rpm, the resulting binary rpms, or both. Example case: an upstream source tarball contains source files under let's say BSD, LGPLv2.1+ and GPLv2+ licenses. That would mean that let's say a binary built from all those would fall under GPLv2+. Specifying GPLv2+ as the License tag would be misrepresenting the copyrights of the files in the source rpm that carry BSD and LGPLv2.1+ notices. Specifying "BSD and LGPLv2.1+ and GPLv2+" would be misrepresenting the copyright of the combined work in the resulting binary. 3) Source licenses are not the only thing that affect the distributables' copyrights. For example when something is built from let's say LGPLv2+ sources but linked with a GPLv2+ library, the resulting binary will be GPLv2+, while the sources are still LGPLv2+ (unless their embedded copyright notices are changed to GPLv2+, but that can't be done for many *GPL licenses). Suggested combined fix for 2) and 3) above: change the licensing guidelines to prominently note something like that the value of the License tag represents the copyright/license info of binary packages only, and only when built in the configuration specified by the Fedora build system, build dependencies/conflicts in the specfile, and no non-Fedora software installed that will affect the build in any way. Source rpms' copyrights are determined by the sources and other content included in them.

5 11

Packaging/Guidelines -> Tags: missing link to the new License Tag Guidelines
by Till Maas 12 Aug '07

12 Aug '07

Hi, on http://fedoraproject.org/wiki/Packaging/Guidelines#head-c17fb8c1ce9be40da72… there is written: | The Copyright tag is deprecated. Use the License tag instead. Use standard | abbreviations and names, e.g. GPL, LGPL, BSD, Artistic. Contact the upstream | author if there is any doubt about what license the software is distributed | under. There should be a link to the License Tag Guidelines imho: http://fedoraproject.org/wiki/Packaging/LicensingGuidelines Regards, Till

3 2

License Tag Draft
by Tom Callaway 12 Aug '07

12 Aug '07

OK, I know this is going to be painful, but we need to solve this (FESCo is waiting for us to do it), and I think this is the cleanest way: Please review: http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag and http://fedoraproject.org/wiki/Licensing . We'll vote on it next week. Thanks, ~spot

18 70

missing file in example in sourceUrl
by Patrice Dumas 11 Aug '07

11 Aug '07

Hello, Unless I am wrong, in https://fedoraproject.org/wiki/Packaging/SourceURL in the generate-tarball.sh code, there is a missing second arg for the second tar invocation, should certainly be tar -czvf libfoo-$VERSION-nopatents.tar.gz libfoo-$VERSION I cannot edit. -- Pat

2 1

New db4 update and package changes
by Jindrich Novy 09 Aug '07

09 Aug '07

Hi folks, you may have noticed Oracle released db-4.6.18 recently. The update is now prepared in CVS, old db-4.5.20 is now moved to compat-db so the new db4 is ready to hit rawhide soon. I want to announce a change I made in the new db4, that may affect you from the packaging POV if your package is dependent on db4. It is that I moved all the C++ stuff to db4-cxx and db4-cxx-devel subpackages to reduce dependency bloat (#220484). If you have any proposals/objections related to the update, please speak up. Thanks, Jindrich -- Jindrich Novy <jnovy(a)redhat.com> http://people.redhat.com/jnovy/

3 2

Texlive packaging and "Errata packages"
by Jonathan Underwood 07 Aug '07

07 Aug '07

Hi, Jindrich Novy has been preparing texlive packages for F8 for a while now, and there are essentially 3 RPMs: telive (the binaries) texlive-texmf (the texmf tree) and texlive-texmf-errata The one I am concerned about is telive-texmf-errata. As Jindrich says "This is the errata package for the TeXLive 2007 formatting system. The purpose of this package is to support updates to huge texmf tree without a need to download all the texmf tree again, but to ship only the fixed parts. texlive-errata puts updated files into a seperate texmf tree which is searched prior to the main tree so there are no conflicts between texlive-errata and texlive-texmf packages." I think this is a totally different packaging paradigm - as far as I'm aware there's no precedent in Fedora for issuing errata packages rather than updated packages. A far better alternative IMO is to have finer grained subpackaging of the texlive texmf tree, such that updates don't replace the whole thing. That of course has other major advantages, such as allowing smaller tex installs. Also, to have *two* system managed texmf trees searched is a big change, and something else that system admins have to think about when they add their own local texmf trees. Put more bluntly, while I understand the convenience from a packagers point of view, this seems like a really ugly way to package. It feels a bit like the ever increasing number of hotfixes you get installed on an M$ system (although there would never be more than a single texmf-errata package installed at a time of course). I know Rex Dieter likes the errata package idea. I wonder what others think? Cheers, Jonathan

6 7

multiple changlog entries for one e-v-r
by Till Maas 06 Aug '07

06 Aug '07

Aloas, is it ok to use multiple changelog entries for one e-v-r? E.g.: %changelog * Thu Jun 15 2003 Joe Packager <joe at gmail.com> - 1.0-2 - Added LICENSE file (#43). * Wed Jun 14 2003 Joe Packager <joe at gmail.com> - 1.0-2 - Added README file (#42). Regards, Till

4 5

Missing this (and maybe next) week's meeting
by Ville Skyttä 06 Aug '07

06 Aug '07

Hi, I'm going to miss this week's FPC meeting, as well as possibly next week's one.

2 1

Package EOL procedure when merging two packages
by Todd Zullinger 03 Aug '07

03 Aug '07

Hola, I want to get a sanity check on something so I don't cause any dep problems. I'm planning to merge the python-gpod package into the main libgpod package (it was originally built separately due to requirements on Extras packages). This is planned for devel first, and then eventually F7. As I understand it, I should: a) add a dead.package file in the devel branch for python-gpod explaining that it's been merged with libgpod, and delete the other files from the branch. b) ask rel-eng to block the package from devel. I'm unsure about b. Can anyone help clarify this and let me know if I'm missing other steps? (The package isn't in comps and will remain in FC6 for sure, and F7 for a little while at least -- so steps 3 and 4 on PackageMaintainers/PackageEndOfLife aren't relevant.) Thanks, -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If quitters never win, and winners never quit, then who is the fool who said "Quit while you're ahead?"

3 3

scrollkeeper snippets
by Jason L Tibbitts III 01 Aug '07

01 Aug '07

Is there some reason the scrollkeeper examples in http://fedoraproject.org/wiki/Packaging/ScriptletSnippets don't redirect output to /dev/null? - J<

4 5

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging August 2007