Proposal: Remove BuildRequires: exceptions from the guidelines
by Jason L Tibbitts III
TL;DR: There's a proposal for nuking the list of BuildRequires
exceptions from the packaging guidelines.
Important note: this is just an idea. We're not currently changing the
guidelines based on this. Nothing is set in stone. It may end up that
nothing happens. Don't panic.
A couple of times recently, people have floated proposals to the FPC
about removing certain things from the buildroot. (Specifically, perl
and gcc*.) And the bottom line for these is that while FPC tries to
maintain a list of BuildRequires: exceptions, this is really up to
releng and whatever rpm happens to pull in at any particular time.
This means that whatever list FPC maintains, it's going to get outdated
eventually, and giving packagers the idea that they don't have to
actually specify all of their dependencies restricts what releng can do
and, perhaps, what dependencies the RPM package can drop without
breaking builds.
So, the generally stated proposal:
I would like to get FPC out of the business of specifying this list of
exceptions, and instead just indicate that packagers should completely
specify their dependencies.
My specific proposal can be seen in
https://fedorahosted.org/fpc/ticket/497; the draft is at
https://fedoraproject.org/wiki/User:Tibbs/BuildReqDraft2. You can use
the history tab to see the differences between that and the current
guidelines.
Now, the real issue is in what packagers can depend upon. Obviously you
have RPM and an environment necessary to build a package (which means
you have to have a shell to execute the scripts that make up the RPM
sections, and redhat-rpm-config, and whatever RPM happens to use to
execute %patch, which I guess could be some internal library if the RPM
devs wanted). But what else? That's the open question.
The draft currently says:
---
You may assume that you have everything necessary for RPM to function
and process your spec file (so of course RPM is present, along with
redhat-rpm-config and what is necessary for RPM to apply patches, unpack
archives, and run the shell scripts which make up the spec file
sections.) You should not assume any other packages are present, as RPM
dependencies and anything brought into the buildroot by the build system
may change over time.
---
Honestly, I'm not completely satisfied with that but I can't come up
with anything better. Polite discussion is welcomed and encouraged.
- J<
8 years, 11 months
Update Java packaging guidelines to reflect current package names
by Jonathan Underwood
Hi,
I've just posted ticket 521 which covers a trivial change to the guidelines:
https://fedorahosted.org/fpc/ticket/521
Currently the packaging guidelines for Java packages say this under the
BuildRequires and Requires section:
Java binary packages or their dependencies MUST have Requires (generated
by RPM or manual) on:
java-headless or java-headless >= 1:minimal_required_version
jpackage-utils
However, on modern Fedora, the jpackage-utils package has been renamed to
javapackages-tools (which obsoletes and provides jpackage-utils). So,
moving forward, really the guidelines should be updates to reflect this. I
propose changing the bullet point which is currently jpackage-utils to
javapackages-tools. I haven't made a draft for this trivial one word
change.
Cheers,
Jonathan.
9 years, 1 month
Summary/Minutes from today's FPC Meeting (2015-03-26 16:00 - 17:50 UTC)
by James Antill
======================
#fedora-meeting-1: fpc
======================
Meeting started by geppetto at 16:00:26 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting-1/2015-03-26/fpc.2015-03-...
.
Meeting summary
---------------
* Roll Call (geppetto, 16:00:27)
* Schedule (geppetto, 16:06:22)
* LINK:
https://lists.fedoraproject.org/pipermail/packaging/2015-March/010526.html
(geppetto, 16:06:26)
* #515 Bundling determination and exception request (geppetto,
16:06:55)
* LINK: https://fedorahosted.org/fpc/ticket/515 (geppetto, 16:07:01)
* ACTION: Can you try to create a static library that all the
components use (geppetto, 16:37:56)
* #516 Bundling exception for Thymeleaf (geppetto, 16:38:03)
* LINK: https://fedorahosted.org/fpc/ticket/516 (geppetto, 16:38:07)
* ACTION: Bundling altered DTDs is fine, assuming the license allows
it (+1:6, 0:0, -1:0) (geppetto, 16:45:54)
* #518 Confusion about '+' in a package name (geppetto, 16:46:10)
* LINK: https://fedorahosted.org/fpc/ticket/518 (geppetto, 16:46:15)
* ACTION: The + here isn't a delimiter, so it's fine to use
(geppetto, 17:02:56)
* #519 Old filters in guidelines example (geppetto, 17:03:40)
* LINK: https://fedorahosted.org/fpc/ticket/519 (geppetto, 17:03:45)
* ACTION: Fix typo in example from __provides_filter_from to
__provides_exclude_from (+1:6, 0:0, -1:0) (geppetto, 17:20:45)
* Open Floor (geppetto, 17:21:24)
* LINK:
https://fedoraproject.org/wiki/Packaging:Per-Product_Configuration
in case anyone is wondering. (tibbs|w, 17:25:35)
* LINK: https://fedorahosted.org/fpc/ticket/508 (tibbs|w, 17:39:19)
Meeting ended at 17:53:42 UTC.
Action Items
------------
* Can you try to create a static library that all the components use
* Bundling altered DTDs is fine, assuming the license allows it (+1:6,
0:0, -1:0)
* The + here isn't a delimiter, so it's fine to use
* Fix typo in example from __provides_filter_from to
__provides_exclude_from (+1:6, 0:0, -1:0)
Action Items, by person
-----------------------
* **UNASSIGNED**
* Can you try to create a static library that all the components use
* Bundling altered DTDs is fine, assuming the license allows it (+1:6,
0:0, -1:0)
* The + here isn't a delimiter, so it's fine to use
* Fix typo in example from __provides_filter_from to
__provides_exclude_from (+1:6, 0:0, -1:0)
People Present (lines said)
---------------------------
* tibbs|w (134)
* geppetto (112)
* orionp (29)
* tomspur (22)
* mbooth (19)
* Rathann (18)
* sgallagh (12)
* zodbot (9)
* SmootherFrOgZ (5)
* stbnruiz (1)
* tibbs (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
9 years, 1 month
sphinx-build to be used in %build or %install
by Parag Nemade
Hi all,
I am doing review of python-oslo-context which needs to build
documentation using sphinx-build command. I saw some python packages
providing documentation files are calling sphinx-build in %install
only.
What will be the correct place to execute sphinx-build command in
%build or %install?
Regards,
Parag.
9 years, 1 month
bundling of jemalloc
by Paolo Bonzini
Firefox and xulrunner are bundling their own copy of jemalloc (try
"strings /usr/lib64/xulrunner/xulrunner |grep jemalloc", or similarly
with /usr/lib64/firefox/firefox-bin).
Why isn't this recorded in the RPM provides (and why is there no mention
of jemalloc in
http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries)? Are
there any other known cases outside Mozilla products? I found bug
788500 about unbundling jemalloc from redis.
Thanks,
Paolo
9 years, 1 month
Packaging a library that creates a Ruby gem...
by Darryl L. Pierce
I have two packages (qpid-cpp and qpid-proton) that, as part of their
source code, can generate a Ruby gem. In both cases the Ruby gem is
directly dependant on shared libraries produced by the codebase, and
those gems are already packaged separately for Fedora.
What I want to do is to create the gem, which is easy, and then install
and package it as a subpackage, which is proving to be hard. The problem
is that the %gem_install macro won't let me override where it looks for
the shared libraries and header files that it needs to create its
makefile.
Is there a way, during the packaging process, to do this? I need to have
the %gem_install macro either accept commandline options
(--without-qpid-lib-dir=[path], for example) or else put things where
they're discoverable by the %gem_install macro.
Any help?
--
Darryl L. Pierce <mcpierce(a)gmail.com>
http://mcpierce.blogspot.com/
Famous last words:
"I wonder what happens if we do it this way?"
9 years, 1 month
