Non-redistributable packages: Skype, spotify, ...

[Alec Leamas]

On 2013-10-30 22:01, Nicolas Chauvet wrote:
> 2013/10/30 Alec Leamas <leamas.alec at gmail.com 
> <mailto:leamas.alec at gmail.com>>
>
>     On the wishlist and/or dead reviews we have some re-distributable
>     packages such as skype, spotify and msttcore-fonts. After
>     scratching my head over these I've hacked some silly scripts ,
>     called them lpf (Local package Factory) and made a package of it.
>     It's on it's way into fedora, currently in rawhide, f20 and  f19
>     updates-testing.
>
>     Using this package it should be simpler to package a thing like
>     spotify. The downloader lpf-spotfy-client is also on it's way into
>     fedora, lpf-skype needs a review.  The overall idea here is to
>     have a common framework for these packages simplifying for both
>     users and packagers. Since they by definition don't contain any
>     upstream stuff they go into fedora rather than rpmfusion, although
>     they are on the rpmfusion wishlist.
>
>     I don't know if this is a good idea. Time will tell,
>
>
> Hello Alec,
>
> I don't get the point to have non-free software "remotely within 
> fedora". But if acceptable I guess it could be possible to have 
> rpmfusion-*free-release in ? (the laters are freely redistributable).
>
> Thx for this initiative...
>
This outcome is kind of a surprise also for me; my gut feeling was that 
these packages would end up in rpmfusion. However, the decision is 
seemingly based on that lpf packages contains nothing from upstream and 
nothing binary.  What they generate is another issue, but Spot's 
decision seems to be that  doesn't really matter, it's not on Fedora  
servers.

I guess that theoretically one could have lpf packages in fedora instead 
of what's in *free now. However, like I said to Simone, for a user a 
re-distributable binary rpmfusion package is a better solution than a 
lpf package which basically is kind of a source distribution. lpf cannot 
really hide the fact that the package must be built, it takes time and 
gives build deps. And, also again, lpf is really designed for leaf 
packages, I don't see what happens if something depends on a lpf package.

Also, the lpf build process is just semi-automated on purpose. A user 
need to be present to accept EULA conditions if required.

Bottom line: lpf is designed as the last resort, when something can't be 
hosted neither on fedora nor rpmfusion. I suggest that we keep it this way.

--alec


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.rpmfusion.org/pipermail/rpmfusion-developers/attachments/20131030/62b59a42/attachment.html>