packaging June 2009

packaging@lists.fedoraproject.org

45 participants
34 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

next FPC meeting
by Toshio Kuratomi 01 Jul '09

01 Jul '09

Hey guys, looks like with all the vacations and conferences that people have been attending, we've lost track of the weeks that we want to be doing meetings again. Spot has another commitment on July 7th. How does July 14th sound for the next one? If there's quorum for a July 7th meeting we can meet then as well/instead.... I'll stick my hand up and say I'm available on both days. -Toshio

5 4

openmpi
by Orion Poplawski 30 Jun '09

30 Jun '09

It seems to me that the removal of the -devel (and possibly -libs) sub-packages from openmpi is a violation of the packaging guidelines. See: https://bugzilla.redhat.com/show_bug.cgi?id=499851 Perhaps the packaging committee could comment? What to do next? No response so far from the packager (1 1/2 months). -- 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

4 3

Generic filtering macros...
by Chris Weyl 30 Jun '09

30 Jun '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

auto req/prov filtering, redux
by Chris Weyl 30 Jun '09

30 Jun '09

So, while checking if there was going to be a FPC meeting today, a couple points came up that seem as if they could use a bit of clarification: * The internal dependency generator is not golbaly turned off; it is only turned off when the filtering macros are actually invoked. * Disabling the internal dependency generator is currently the only way to enable the filtering of errant solib dependency information. * File coloring only impacts us via multilib in the case of elf32/64 executable binaries (w.r.t. disabling the internal dependency generator). [1] * Clean, consistent autoreq/prov overriding is clearly needed: there are hundreds of packages disabling the internal dep generator, hundreds more with some form of req/prov filtering, and recent questions on fedora-devel-list as to overriding this sort of dep. In other words, to make these macros available globally will have no impact on any package not explicitly using them. (Note the %expand macro being used in %setup_filter[2]) solib-provoked "provides" can be filtered from packages not providing elf32/64 executable binaries without messing up multilib. (That is, all arch-specific perl packages, pidgin/mysql/etc plugin packages, etc.) Is any of the above wrong? Are there any specific objections that would prevent the adoption of this proposal, beyond bikeshedding? -Chris [1] http://article.gmane.org/gmane.linux.redhat.fedora.extras.packaging/5889 [2] http://fedorapeople.org/~cweyl/macros.filtering -- Chris Weyl Ex astris, scientia

1 0

Java packaging questions about rpmlint messages
by Bruno Wolff III 29 Jun '09

29 Jun '09

I am working on packaging a java game and have a couple of rpmlint messages that I am not sure if I can ignore. One is an error for having no binaries. I thought the java stuff was somewhat arch dependent, so I thought my resulting jar file should be arch dependent and that overriding the buildarch would be a bad idea? The second is a warning for including a classpath in the manifest. The original package is setup to have a class path point to a library with a few included jar files. Only one of these jars is needed and is already packaged for Fedora. For the build process I override the property saying where the libs are to point to the Fedora jar directory. But this gets left in the manifest. To run the program I have a shell script that includes the two jar files and gives the class name to run. So while not being able to give a usable classpath on the java command line is annoying, it isn't a big deal in this case. Is this out and out broken? Is there a way to do it better without having to do too much customization of the original projects build.xml file? (ant is used to do the build.)

3 4

[Draft]Policy for creating filesystem subpackages
by Jochen Schmitt 28 Jun '09

28 Jun '09

Hallo, I have create a draft for a guildlines, which described under which condiition a so-called filsystem subpackages has to been created. The draft you may find at: https://fedoraproject.org/wiki/PackagingDrafts/CreatingFilesystemSubpackages Best Regards: Jochen Schmitt

3 2

libspotify
by Paul F. Johnson 28 Jun '09

28 Jun '09

Hi, I'm considering packaging libspotify (it's a library for accessing the spotify music service), but it has a couple of problems. The licence is MIT, which is fine. However, for a user to be able connect to spotify, they have to email spotify to obtain a file which registers them. It also requires a .la file which is against the packaging rules. Spotify have very little interest in their library, so there would probably be little that they would do to remove this .la file and without it, the package won't install locally. Any comments or advice on this? TTFN Paul -- Sie können mich aufreizen und wirklich heiß machen!

4 4

removal of pre-built files
by Orcan Ogetbil 28 Jun '09

28 Jun '09

Hi, Toshio asked me to write up a proposal for clarification of the removal of pre-built binaries. I came up with two proposals. I'd like to have them considered and voted separately. https://fedoraproject.org/wiki/PackagingDrafts/Removal_of_pre-built_binaries Any comments, suggestions welcome. Orcan

9 20

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging June 2009