"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.
13 years, 9 months
F-11 to F-12 transition
by Federico Hernandez
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
13 years, 9 months
next FPC meeting
by Toshio Kuratomi
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
13 years, 11 months
openmpi
by Orion Poplawski
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
13 years, 11 months
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
13 years, 11 months
auto req/prov filtering, redux
by Chris Weyl
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
13 years, 11 months
Java packaging questions about rpmlint messages
by Bruno Wolff III
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.)
13 years, 11 months
libspotify
by Paul F. Johnson
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!
13 years, 11 months
