Re: Packaging 3-rd party repositories in rpmfusion
On 2/3/14, Xavier Bachelot <xavier(a)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