[Fedora-packaging] #15 relaxing guidelines wrt. bundling

Stephen Gallagher sgallagh at redhat.com
Mon Nov 1 10:33:38 UTC 2010


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/31/2010 12:50 PM, Stephen John Smoogen wrote:
> 2010/10/31 Toshio Kuratomi <a.badger at gmail.com>:
>> On Sat, Oct 30, 2010 at 12:01:25AM +0100, Jeroen van Meeuwen wrote:
>>> Toshio Kuratomi wrote:
>>>
> 
>> Possible how:  Allow apps to bundle libraries period.
>> Possible why: Because users are going to run the apps anyway and if they
>> come from Fedora, at least we can be providing updates to the broken
>> versions as the fixes become available instead of relying on the user to
>> seek them out.
>>
>> Possible how: Apps are allowed to bundle libraries as long as the maintainer
>> commits to keeping the app ported to the newest version of the bundled
>> library within Fedora at all times.
>> Possible why: Security fixes and bugfixes to the library are going to be
>> pushed to the latest versions of packages in Fedora.  We need to make sure
>> that the libraries are kept in sync so that we can consume those fixes
>> quickly if a problem arises.  We need to make sure that there is someone
>> able to make fixes (the maintainer) in case a problem arises.
>>
>> Possible how: Apps that bundle libraries must get a commitment from FES that
>> FES will maintain code in the apps should it be needed.  The commitment must
>> be made for every release that Fedora is released for.
>> Possible why: FES is available to do coding work on the distribution.
>> If they sign up for maintaining a package's code, the maintainer does not
>> need to know how to program (only package).  FES, being a group, allows
>> greater flexibility for fixing issues quickly should a security issue need
>> a quick turn-around.
>>
>> Please add more suggestions -- I'm not really satisfied with any of these
>> so there's definitely room for improvement here.
>>
> 
> The creation of the "crap" repository. This area runs under less
> restrictive packaging guidelines in order to allow for future
> inclusion with the mainline. Things that would NOT be allowed in it:
> 
> 1) Software that violates our Freedom clause (eg nonfree is a no-no).
> 2) Software that violates legal restrictions (patents, trademarks, and
> similar software).
> 
> Software in this repository would be allowed to bundle libraries, but
> would follow packaging guidelines. Due to the fact the software may
> need regular updates to remain stable it would be allowed updates
> during a release. It would not be QA'd beyond changes to the spec file
> would need to be reviewed (like old fedora.us ways). It would not
> override software in Fedora (thus it is either in the release or its
> in "Crap" but not both).
> 
> Other repository names could be "feces", "fewmets", cow pies, cowplop,
> road apples, fertilizer, guano, manure, meadow muffin, night soil,
> ordure, poop
> 


See my post from October 29th to this list about using the FedoraPeople
repositories for this purpose, with the added benefit of NOT having
these packages signed (and therefore, official) parts of the Fedora project.

- -- 
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkzOl34ACgkQeiVVYja6o6NCbQCeIF3YBtWzN5qqTeNEPtG99JAe
VlgAoIe7KqgaKU5Si6eznp/19m/OMoux
=WEJX
-----END PGP SIGNATURE-----


More information about the packaging mailing list