packaging July 2009

packaging@lists.fedoraproject.org

45 participants
32 discussions

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

09 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

F-11 to F-12 transition
by Federico Hernandez 01 Sep '09

01 Sep '09

Now this might really be a newbie question but since I haven't maintained a package that long yet I wonder how the transition now from F-11 to the future F-12 works. At what point can/must I check out a new CVS branch for F-12 of my package? Will it be created automatically and all the packages in rawhide will move by magic into F-12? Or do I need to request one via bugzilla? Just wondering as I have never been around for this transition. Greetings, /Federico

3 5

MPI and Fortran drafts
by Susi Lehtola 26 Aug '09

26 Aug '09

Hello again, I have updated the MPI draft at https://fedoraproject.org/wiki/PackagingDrafts/MPI to take into account the comments that araised in discussion on the list. As I have been dealing with quite a few Fortran packages I have realized that the current laissez-faire mentality may not be enough and a standard is needed for file placement. https://fedoraproject.org/wiki/PackagingDrafts/Fortran As before, comments are welcome. -- Jussi Lehtola Fedora Project Contributor jussilehtola(a)fedoraproject.org

4 14

Environment-modules & MPI drafts
by Susi Lehtola 29 Jul '09

29 Jul '09

Hi, I think I am reasonably happy with the current versions of the Environment modules and MPI drafts, as they should cover everything. The environment module part is quite simple, the MPI part took quite some amount of work to get everything (such as Python and Fortran modules) in it. For a while I was not quite sure which was better: not having an MPI binary suffix, or having one. On one hand not having a suffix may be easier on behalf of the user (then again running the serial version is harder when an MPI module is loaded). On the other hand, I think that it's better to run the wanted MPI version explicitly instead of blindly trusting what is in the $PATH. For consistency in binary naming we MUST have a guideline on the suffixes. My gut feeling is that suffixing is better (normally MPI enabled software makefiles produce suffixed binaries when MPI is on), thus I have ended up with suffixes (if nobody has strong negative feelings about this). As F12 is drawing nearer quite fast, I'm hoping for these guidelines to be decided upon ASAP, so the packaging side can be taken care of in time. -- Jussi Lehtola Fedora Project Contributor jussilehtola(a)fedoraproject.org

1 0

ScriptletSnippets weirdness
by Gianluca Sforna 29 Jul '09

29 Jul '09

I just noticed the page: https://fedoraproject.org/wiki/Packaging:ScriptletSnippets has a weird syntax in gconf scriptlets: export GCONF_CONFIG_SOURCE=<code>gconftool-2 --get-default-source</code> The old wiki page looks good: http://fedoraproject.org/wikiold/Packaging/ScriptletSnippets so I think that was a conversion issue. -- Gianluca Sforna http://morefedora.blogspot.com http://www.linkedin.com/in/gianlucasforna

2 2

Many unowned directories in /usr/share/man
by Axel Thimm 28 Jul '09

28 Jul '09

Hi, there are some locale that are unowned under /usr/share/man. These directories need to be owned by a package. Many of the more used locales are owned by man/man-pages, but some more exotic are not. It looks like there are about 63 unowned directories coming from the following locale ca da eo es et gl hu id nb nl nn pt pt_BR sk sr sv tr zh_CN zh_TW https://bugzilla.redhat.com/show_bug.cgi?id=220265#c17 The current suggestion is to have the package with the man pages to own these, for example the subtree under /usr/share/man/sv/ shoule be owned by dcraw-8.91-1.fc11.x86_64 fakeroot-1.12.2-21.fc11.x86_64 jwhois-4.0-13.fc11.x86_64 shadow-utils-4.1.2-13.fc11.x86_64 This doesn't seem like a clean or scaling solution and I think it would be better to have these owned by man/man-pages. This probably requires a new guideline, could you please push a matching guideline out, or perhaps just clarify what's there, as I think the intention of the guideline is indeed that the man* packages should own all such directories. -- Axel.Thimm at ATrpms.net

8 9

MPI draft & EPEL specific packages
by Susi Lehtola 28 Jul '09

28 Jul '09

Hi, I have added today the Fortran and Python module locations to the MPI draft, and written a bit about the required changes. http://fedoraproject.org/wiki/PackagingDrafts/MPI Related to the draft, what's the process of getting EPEL specific packages? An unified interface on Fedora and EPEL would require a wrapper package for openmpi and lam on RHEL 4 and 5. And last: is the FPC meeting today? I couldn't find any meeting schedules. -- Jussi Lehtola Fedora Project Contributor jussilehtola(a)fedoraproject.org

2 1

"Code versus Content" clarification
by Christian Krause 27 Jul '09

27 Jul '09

Hi, During one of my last reviews I've stumbled again over some "Code versus Content" issues. After reviewing https://fedoraproject.org/wiki/Packaging:Guidelines#Code_Vs_Content carefully I've come to the following understanding: Legal status of the content --------------------------- If Fedora somehow publishes the files in any form (source or binary RPM) then they must be under an acceptable license and redistribution must be legally permitted. Additionally it must met the Fedora's criteria described in the packaging guidelines (content should not be offensive, no mp3 files, ...). If the legal as well as Fedora's criteria are not met, the files must not be shipped in any way and so they must be even stripped off from the source files. Question 1: How much investigation is needed from the packager or reviewer? Is asking upstream for an official statement sufficient? Content or example ------------------ If the files can be considered as examples they can just be included in the packages without any interaction with FeSCO. The explicit criteria is not defined, but the following seems quite logical to me: If the files contain rather small demonstrations of the package's capabilities then they are examples (e.g. some midi files in an audio related package). If the files contain a rather detailed or complete work (e.g. if the midi file would contain a thoroughly arranged concert), then they are clearly content. Question 2: If it is undecided, who should make the final decision whether something is just an example? Inclusion of content -------------------- If the files are considered as "real" content and are legally permissable then FeSCO has the final word about the inclusion. Does this summary reflects the intention behind the packaging guidelines correctly? Best regards, Christian

2 1

Merge-review questions....
by Parag Nemade 27 Jul '09

27 Jul '09

Hi, I got some questions on Merge-reviews 1) If as per review guidelines merge-review of any package does not got any blocker but missing to follow some packaging guidelines like missing to follow timestamps, should I just ask in review and approve that merge-review or wait for developer to fix spec file? 2) If developer does not replies within a month time or asking me as a reviewer to commit in cvs what should I do for merge-review (Assume I am always there to help and complete merge-review)? Thanks & Regards, Parag.

2 1

Fedora Packaging Committee Seat Filled
by Tom Callaway 27 Jul '09

27 Jul '09

Thanks to everyone who applied for this open seat. We got a lot of very qualified individuals who were interested in filling the open seat on the Fedora Packaging Committee. After much discussion and thought, I've asked Jon Ciesla to fill the open seat and he has accepted. I'm sure that we will have additional openings on the FPC in the future, as people move on to other tasks, or get committed to various mental institutions. ;) Please feel free to throw your name in the ring for future openings! A few points that I felt might be worth making: * If you're not an active package maintainer in Fedora, it definitely hurts your chances of being on the FPC, as we're always looking for people who are intimately involved with Fedora packaging. * If you haven't done many Fedora Package Reviews, it's a great way to increase your visibility in the Fedora Packaging Community space, and also is a good way to show us that you have a solid understanding of the existing Fedora Packaging Guidelines. Plus, it helps us get new packages into Fedora! Thanks again to all who applied, ~spot

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging July 2009