I've been getting some conflicting advice as to what to do about moving
a patent unencumbered version of package that has existed in RPMFusion
for some time.
The package is qtractor (a digital audio workstation/ sequencer),
software we'd like to showcase as part of Fedora 18's Audio Spin.
Removing libmad (MP3) library deps was simple enough via a compile time
flag and a Review request was raised . Using
audacity/audacity-freeworld as a precedent it was suggested that we
rename qtractor in RPMfusion to qtractor-freeworld and have it Conflict:
with Fedora's qtractor.
The problem here is that RPMFusion users may have their libmad version
silently replaced by the one in Fedora during the transition.
One solution here is to leave qtractor as it is in RPMfusion and rename
the one in Fedora to something else (qtractor-free?) and perhaps use
alternatives to permit coexistence, removing the need for conflicts
Is this reasonable?
Is it possible for man pages to use the %doc macro in the %files section in a spec file? In Guidelines, there's no explicit mention of it, and I haven't found a package having this behavior. However, I am reviewing spacewalk-pylint ( https://bugzilla.redhat.com/show_bug.cgi?id=800899 ), which does this:
Can you please give me a stance on that?
Tomas Radej <tradej(a)redhat.com>
Hey guys, I'm guessing that packaging a library must be a somewhat
different process than packaging other software (because a library and a
devel package must be produced), but I am not clear on what those
differences are. I.e, what special information does the SPEC file
require? Are the rpmbuild commands any different?
I'd be glad to be pointed to the correct documentation. There didn't
seem to be a section covering this in the Fedora RPM guide.
-----BEGIN PGP SIGNED MESSAGE-----
Is it permissible to use a single compat package to provide different
'compat' binary packages on different Fedora releases?
The specific use case is for Vala: our Fedora packaging now allows for
parallel installation; you already can rebuild and install Vala
packages with different API levels side by side.
Vala upstream tends to create new API releases quite often, however,
and given that sometimes packages stop compiling against the newer
API, providing API-specific compatibility versions seems to be a lot
of work (and the package would have to be retired as soon as the
targeted release is EOLed).
Does the FPC allow having a single 'compat-vala' Git module, that
would target the API level one lower than the one shipped in the main
vala package, for every supported Fedora release? The package will be
very similar to the main vala one and changes can just be
cherry-picked, so maintenance is no problem.
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
I'm the packager of APLpy: http://aplpy.github.com/
I'm going to update it to a new version, which comes with a set of
tests, but I'm not sure about what to do with them. I asked upstream and
the answer is:
"The tests are there for us to diagnose any issues related to specific
dependency versions and platforms, and to make sure that we don't
break anything when making changes. It would be useful if you include
them so that we can ask users to run them if they are having issues we
can't reproduce, but you don't need to run the tests as part of the
I'm still not sure. Should I include them in the package?
Have a nice day,
Germán A. Racca
Fedora Package Maintainer