Packaging 3-rd party repositories in rpmfusion

Alec Leamas leamas.alec at gmail.com
Wed Jan 29 13:33:25 CET 2014


>On 1/29/14, Andrea Musuruane <musuruan at gmail.com> wrote:
>> On Wed, Jan 29, 2014 at 12:12 PM, Alec Leamas <leamas.alec at gmail.com>
>> wrote:
> At the start of RPM Fusion we had a sort of steering committee which
> handled such decisions (IIRC Hans, Matthias and Thorsten). Each of them
> represented one of the repositories merged in RPM Fusion (Dribble,
> Freshrpms, and Livna).
>
> It could be good to have such a committee back.
Yes, I wondered about this... we really need a way to adapt.

>> - We already have a list of endorsed 3-rd party repos [4].
>>
> That list is not endorsed in any way by RPM Fusion. It is just a list of
> third party repositories made for user convenience, some of which are known
> to work well (i.e. without conflicts) with RPM Fusion.
OK. Then my proposal includes changing the official status of this
list (which certainly will require an update).

And of course, from a user perspective: why shouldn't it be easy to
use those repos which we know actually works with rpmfusion? From a
legal POV there shouldn't be much difference between recommending a
manual install and some tooling making it as long as user makes the
final decisions.

> As RPM Fusion follows Fedora guidelines and at present Fedora forbids to
> ship third party repositories, we should do the same.
Actually, they don't just forbid shipping repos  - there is mechanisms
and policys for exemptions, and they are obviously intended to be used
 (GL are *really* new).  It's just that those policys and decision
making processes are not applicable for rpmfusion. That's why we need
to interpret this for our own needs in a meaningful way.

That said, I agree that unless we can change the rules of the game for
rpmfusion (probably requiring some kind of steering body) we probably
cannot ship a yum 3-rd party repository as things are right now.

Which seems to boil down to that rpmfusion lacks decision-making capabilities.

--alec


More information about the rpmfusion-developers mailing list