Packaging 3-rd party repositories in rpmfusion

[Alec Leamas]

On 2/3/14, Xavier Bachelot <xavier at bachelot.org> wrote:
[cut]
> I'm in agreement with Ralf too.
> imho, one of the biggest "selling point" for repositories like RPM
> Fusion is the insurance the Fedora packaging guidelines are enforced and
> thus the packages will integrate properly with the remaining of the
> ecosystem. Some other repositories, including some that are proposed for
> integration in RPM Fusion, are well known for theit low quality
> packaging, hence the need for smart tricks like lpf. I think this bears
> a high risk to backfire on unsuspecting users, and from my
> understanding, providing more lpf packages is probably a better
> solution, even if the maintenance cost is indeed higher.
>
> Regards,
> Xavier
>

lpf is really designed for the case there is a vendor which doesn't
offer prebuilt rpms. The typical example is spotify, which only offers
debian packages. In this case lpf is the only reasonable solution,
providing a framework for repackaging which also works around
non-redistributable license terms.

We can also use lpf to repackage the upstream package if it's quality
makes it necessary - the flash plugin package is an example.

However, IMHO we only should use this solution for something like
dropbox where the vendors provides prebuilt rpms in a yum repository
if there is compelling reasons to do so.  Using lpf means more
maintenance work,  a more legally complicated situation (we are
distributing instead of the vendor), build chain dependencies and
non-transparent user handling (user must "update" the lpf package i.
e., build the target package before use).

To just package the dropbox repositories is so much simpler and easier
to understand. That is reason enough in my eyes.

Cheers,

--alec