[Guidelines Change] Changes to the Packaging Guidelines
by Tom Callaway
Some changes to the Fedora Packaging Guidelines have been made:
---
In the specific case where multiple software components generate
identically named (but incompatible) binaries, Fedora Packagers should
make every effort to convince the upstreams to rename the binaries to
resolve the conflict (see: Packaging:Conflicts#Binary_Name_Conflicts).
However, if neither upstream is willing to rename the binaries to
resolve the conflict, AND the binaries are not viable candidates for
alternatives or environment modules (incompatible runtimes), as long as
there are no clear cases for both packages to be installed
simultaneously, explicit Conflicts are permitted at the packager's
discretion. Both packages must carry Conflicts in this case.
Be aware, adding explicit Conflicts means that if any other packages
depend on your package, you may be creating a chain-of-conflicts that
could cause user pain. Please consider this as a last resort.
https://fedoraproject.org/wiki/Packaging:Conflicts#Incompatible_Binary_Fi...
---
The PEAR section of the PHP Guidelines has been updated to reflect the
existence of a new macro, %{pear_metadir}, along with an example of how
it is to be used, and a new EPEL specific section relating to the fact
that %{pear_metadir} does not exist in RHEL php builds.
https://fedoraproject.org/wiki/Packaging:PHP#PEAR_Modules
---
The MPI Guidelines have been updated to install the module files under a
"mpi" sub-directory and adds "conflict mpi" to the module files to avoid
being able to load multiple mpi modules at one time.
https://fedoraproject.org/wiki/Packaging:MPI
---
These guideline changes were approved by the Fedora Packaging
Committee (FPC).
Many thanks to Remi Collet, Orion Poplawski, Michal Sekletar, and all of
the members of the FPC, for assisting in drafting, refining, and passing
these guidelines.
As a reminder: The Fedora Packaging Guidelines are living documents! If
you find something missing, incorrect, or in need of revision, you can
suggest a draft change. The procedure for this is documented here:
https://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure
Thanks,
~tom
11 years, 1 month
Self-hosting LLVM/Clang?
by Michel Alexandre Salim
Fedora's policy is to not depend on LLVM/Clang as much as possible, but
would it be acceptable to use LLVM/Clang to compile newer LLVM and Clang
releases?
Some more experimental features (such as LLDB, which some developers
have been asking for) appear to be better tested with Clang.
For example: http://lldb.llvm.org/build.html
the "make CXXFLAGS=-std=c++11" suggested at the bottom applies only to
clang and is unrecognized by GCC.
I can file an FPC request if necessary, but would like to check with the
list first whether it's a sensible thing to have or not.
Best,
--
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/
Email: salimma(a)fedoraproject.org | GPG key ID: A36A937A
Jabber: hircus(a)jabber.ccc.de | IRC: hircus(a)irc.freenode.net
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
11 years, 1 month
Fwd: [fpc] #229: New mpi module install location and content
by Orion Poplawski
-------- Original Message --------
Subject: [fpc] #229: New mpi module install location and content
Date: Fri, 26 Oct 2012 04:25:50 -0000
From: fpc <trac(a)fedorahosted.org>
Reply-To: nobody(a)fedoraproject.org
To: undisclosed-recipients:;
#229: New mpi module install location and content
-----------------------------+------------------
Reporter: orion | Owner:
Type: task | Status: new
Priority: minor | Milestone:
Component: Guideline Draft | Version:
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------
I've put up a revised version of the mpi package guidelines here:
https://fedoraproject.org/wiki/PackagingDrafts/MPI
The change is to install the module file under a "mpi" sub-directory and
and "conflict mpi" to the module file to avoid being able to load multiple
mpi modules at one time. See
https://bugzilla.redhat.com/show_bug.cgi?id=651074 for some background.
This has already been done in the openmpi package, but not yet in the
mpich2 package, but I believe it should. This is a common standard to use
with environment modules. In fact it calls for a revision of that
guideline as well, which I'll try to get to soon.
--
Ticket URL: <https://fedorahosted.org/fpc/ticket/229>
fpc <https://fedoraproject.org/wiki/Packaging:Committee>
Fedora Packages Collection Task Tracking
11 years, 1 month
Multiple packages with the same base name versioning
by Vít Ondruch
Hi,
Since my original proposal [1] was rejected, before there was even
single attempt to improve my draft, I am moving this topic here in hope
that somebody can build upon it:
```
Always consider to let a nonversioned package to follow an upstream
release versions. The other versions of package kept in Fedora for
compatibility reasons should be either prefixed by compat- prefix or
their name should be suffixed by version string.
For example, lets have in Fedora foo package of version 1.0 (foo-1.0)
while upstream releases version 2.0.
1. If you are reasonably sure that the 1.0 version of foo package will
be needed just temporary, then update the original package to
foo-2.0 and introduce compat-foo-1.0 package.
2. If there might be more then one older version of library, then
migrate the foo-1.0 to foo-2.0 and introduce the compatibility
package foo1-1.0 or optionally foo10-1.0 package (the version in
name depends on versioning scheme used by upstream).
Try to avoid foo2-2.0 package as much as possible, since it prevents
innovation and make package version irrelevant.
```
There was also a lot of valid feedback on FPC meeting [2], so I hope you
guys are going to elaborate here.
Thank you.
Vit
[1] https://fedorahosted.org/fpc/ticket/227
[2]
http://meetbot.fedoraproject.org/fedora-meeting-1/2012-10-24/fpc.2012-10-...
11 years, 1 month
Re: [Fedora-packaging] [perl-Coro] Work-aroung missing libecb package on build-triggering host
by Ralf Corsepius
On 10/22/2012 03:47 PM, Petr Pisar wrote:
> commit e00f8293097f8331883f1df35f74be70fbb290b9
> Author: Petr Písař <ppisar(a)redhat.com>
> Date: Mon Oct 22 15:46:27 2012 +0200
>
> Work-aroung missing libecb package on build-triggering host
>
> perl-Coro.spec | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
> ---
> diff --git a/perl-Coro.spec b/perl-Coro.spec
> index 50a855d..31589a5 100644
> --- a/perl-Coro.spec
> +++ b/perl-Coro.spec
> @@ -35,7 +35,7 @@ Requires: perl(EV) >= 3
> Requires: perl(Event) >= 1.08
> Requires: perl(Guard) >= 0.5
> Requires: perl(Storable) >= 2.15
> -Provides: bundled(libecb) = %(rpm -q libecb --qf '%{VERSION}')
> +Provides: bundled(libecb)%(rpm -q libecb --qf ' = %{VERSION}' 2>/dev/null)
I could be wrong, but IIRC, calling rpm inside of rpm specs is not
allowed in Fedora.
Apart of this, what you are doing is rendering your built
non-deterministic - Another "strictly forbidden" item.
Ralf
11 years, 1 month
Rules for obsoleting or conflicting packages
by Mario Blättermann
Hi all,
I'm currently reviewing the following package:
https://bugzilla.redhat.com/show_bug.cgi?id=865535
The package python-datanommer-models seems to be a splitout from
datanommer, that's why we have currently:
Conflicts: datanommer < 0.2.0
In my mind, it should be "Obsoletes" instead of "Conflicts" because it
is the successor of datanommer. But we have a somewhat more difficult
scenario here. The packager writes:
"Regarding the Conflicts/Obsoletes/Provides, I'd like to still maintain
the datanommer package itself as a kind of meta-package that installs
the splitoffs but also includes "fedmsg-hub" which will turn on a new
service. Once these packages are approved, I would bump the datanommer
meta package from 0.1.8 to 0.2.0 to match them."
Could we split out the appropriate files from datanommmer instead,
throwing away the new review request? Means, we have a "datanommer" base
package which is a metapackage only with some common files, which pulls
the needed dependencies. Any ideas for a convenient solution while
keeping a proper upgrade path?
Best Regards,
Mario
11 years, 1 month
Unbundling oscpack and boost libraries under review
by Brendan Jones
Hi all,
I'm porting supercollider (sc - an audio synthesis engine and
programming language[1]) from CCRMA to Fedora. The source tree has a
couple of bundled static libraries which I'm not sure meet grounds for a
bundling exemption.
1. oscpack (open sound control) - the bundled version is significantly
different from upstream. The author of sc has submitted patches but they
were not accepted by oscpack upstream
2. boost_lockfree and boost_atomic - the sc author is the boost dev of
boost_lockfree but not boost_atomic. Both libraries have been submitted
to the upstream boost team for inclusion but are not yet available
outside of trunk (lockfree has been approved but is waiting on review of
atomic [2]).
Eventually these will become part of a boost release but not for a while
(boost 1.53 or later)
Are these good grounds for exemption, or should we wait and simply let
CCRMA host the supercollider package until they become available?
[1] http://supercollider.sourceforge.net/
[2]
https://svn.boost.org/trac/boost/wiki/ReviewScheduleLibraries#Boost.LockFree
Brendan
11 years, 1 month
