Re: Non-redistributable packages: Skype, spotify, ...
On 2013-10-30 22:01, Nicolas Chauvet wrote:
2013/10/30 Alec Leamas <leamas.alec(a)gmail.com
<mailto:leamas.alec@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
Attachments:
- attachment.html (text/html — 3.7 KB)