"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, 6 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, 6 months
Environment-modules & MPI drafts
by Susi Lehtola
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
13 years, 8 months
Many unowned directories in /usr/share/man
by Axel Thimm
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
13 years, 8 months
MPI draft & EPEL specific packages
by Susi Lehtola
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
13 years, 8 months
"Code versus Content" clarification
by Christian Krause
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
13 years, 8 months
Merge-review questions....
by Parag Nemade
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.
13 years, 8 months
Fedora Packaging Committee Seat Filled
by Tom Callaway
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
13 years, 8 months
