11:12 a.m.
Formally, this is about review request 3152 for dropbox-repo [1]. From
a more practical POV, it's about users being able to install software
like dropbox more or less "out of the box", an area where I think we
really need to improve (as can be seen in all those "Fedora XX post
installation guide" out there).
My basic understanding is that current Fedora guidelines needs a
interpretation in the rpmfusion context. Those brand new GL for 3-rd
party repos are in [2] (discussions in [3]). For now, I think they can
be abridged to:
- Non-free repos can not be part of Fedora yum configuration.
- In some cases free repos can be part of the configuration after
FESCO/Fedora legal approval.
Now, IMHO this doesn't really make much sense for rpmfusion for three reasons:
- rpmfusion does not ban non-free software, it's one of the very
reasons it exists.
- FESCO/Fedora legal cannot approve anything in rpmfusion.
- We already have a list of endorsed 3-rd party repos [4].
To handle this, my simple proposal is that we handles packaged yum
repositories like this:
- It's ok to package yum repositories listed in [4].
- If anyone wants to change the list in [4] this should be announced
here on rpmfusion-devel, and not done until we agree on it (similar to
how we handle bundling exceptions).
Thoughts. out there?
--alec
[1] https://bugzilla.rpmfusion.org/show_bug.cgi?id=3152
[2] https://fedoraproject.org/wiki/Third_Party_Repository_Policy
[3] https://fedorahosted.org/fesco/ticket/1201#comment:32
[4] http://rpmfusion.org/FedoraThirdPartyRepos
11:50 a.m.
On Wed, Jan 29, 2014 at 12:12 PM, Alec Leamas <leamas.alec(a)gmail.com> wrote:
Formally, this is about review request 3152 for dropbox-repo [1].
From
a more practical POV, it's about users being able to install software
like dropbox more or less "out of the box", an area where I think we
really need to improve (as can be seen in all those "Fedora XX post
installation guide" out there).
My basic understanding is that current Fedora guidelines needs a
interpretation in the rpmfusion context. Those brand new GL for 3-rd
party repos are in [2] (discussions in [3]). For now, I think they can
be abridged to:
- Non-free repos can not be part of Fedora yum configuration.
- In some cases free repos can be part of the configuration after
FESCO/Fedora legal approval.
Now, IMHO this doesn't really make much sense for rpmfusion for three
reasons:
- rpmfusion does not ban non-free software, it's one of the very
reasons it exists.
RPM Fusion doesn't ban non-free software, but it does not allow non
redistributable software. It is not a place to ship everything regardless
of its license.
- FESCO/Fedora legal cannot approve anything in rpmfusion.
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.
- 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.
To handle this, my simple proposal is that we handles packaged yum
repositories like this:
- It's ok to package yum repositories listed in [4].
- If anyone wants to change the list in [4] this should be announced
here on rpmfusion-devel, and not done until we agree on it (similar to
how we handle bundling exceptions).
Thoughts. out there?
As RPM Fusion follows Fedora guidelines and at present Fedora forbids to
ship third party repositories, we should do the same.
Regards,
Andrea.
12:33 p.m.
On 1/29/14, Andrea Musuruane <musuruan(a)gmail.com> wrote:
> On Wed, Jan 29, 2014 at 12:12 PM, Alec Leamas <leamas.alec(a)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
12:30 a.m.
On Wed, 2014-01-29 at 12:12 +0100, Alec Leamas wrote:
To handle this, my simple proposal is that we handles packaged yum
repositories like this:
- It's ok to package yum repositories listed in [4].
- If anyone wants to change the list in [4] this should be announced
here on rpmfusion-devel, and not done until we agree on it (similar to
how we handle bundling exceptions).
Thoughts. out there?
--alec
Hi,
I think it's OK to ship third party repository configurations in rpm
packages at rpmfusion. For instance, a rpmfusion-dropbox that contains
the single dropbox.repo file is fine. We're not redistributing the
software itself, we're just providing the repository configuration that
will enable users to skip going to each individual site and setting it
up themselves. This would also cement rpmfusion as *the* go-to place for
end users. While I wouldn't want such a package to go into Fedora since
it holds a much more strict line between free and non free software, I
think RPMFusion's slightly more relaxed principles permit this.
http://rpmfusion.org/FoundingPrinciples
This:
'this includes software with public available source-code that has "no
commercial use"-like restrictions'
would mean that we shouldn't. However, we're not providing the software,
just the configuration files.
I also hope that this will help reduce the number of users resorting to
third party scripts that set stuff up for them without knowing what
these scripts actually do. At least this way, they'll know exactly what
packages are being installed.
One concern is that some of the rpms that third parties provide do ship
their own repo files. So, after the user installs a package, he might
end up with two repo files? We'll have to use proper conflicts in the
specs. What about GPG keys? (The adobe-release package ships a repo file
and a GPG key.)
If we do go down this path, I'd also suggest that we include a README
file with each such package that clearly states:
- this is only a repo file
- it just points you to the repository hosted by the third party
- you're getting the software directly from the vendors repository
- it is only for convenience
- we cannot support bug/feature requests; they go upstream (or wherever)
- the source code of this software is not available. Please use at your
own risk, i.e., you trust the developer.
Lastly, we may need to speak to the third party devs and confirm if it's
OK to ship their repo files in the first place?
--
Thanks,
Warm regards,
Ankur (FranciscoD)
http://fedoraproject.org/wiki/User:Ankursinha
Join Fedora! Come talk to us!
http://fedoraproject.org/wiki/Fedora_Join_SIG
11:03 a.m.
On Mon, Feb 03, 2014 at 11:30:42AM +1100, Ankur Sinha wrote:
One concern is that some of the rpms that third parties provide do
ship
their own repo files. So, after the user installs a package, he might
end up with two repo files? We'll have to use proper conflicts in the
specs. What about GPG keys? (The adobe-release package ships a repo file
and a GPG key.)
If RPMFusion ships configuration for other repos, the package should
also include the GPG key, set gpgcheck=1 and include only the intended
packages with includepkgs to minimise security problems.
Regards
Till
12:09 p.m.
If RPMFusion ships configuration for other repos, the package should
also include the GPG key, set gpgcheck=1 and include only the intended
packages with includepkgs to minimise security problems.
Regards
Till
I have done some examples in the system-config-repo upstream, all
includes the gpg key. (and system-config-repo has some basic tooling
to inspect it, should be improved).
All examples I have looked into so far, is basically just to make a
specific application available. As long as this is technically sound
(no idea, never used this one) the includepkgs idea looks great to
me.
Cheers,
--alec
1:51 p.m.
On 2/3/14, Ankur Sinha <sanjay.ankur(a)gmail.com> wrote:
[cut]
One concern is that some of the rpms that third parties provide do
ship
their own repo files. So, after the user installs a package, he might
end up with two repo files? We'll have to use proper conflicts in the
specs. What about GPG keys? (The adobe-release package ships a repo file
and a GPG key.)
There are already examples in system-config-repo usptream [¡] dealing
with the situation when the repo file is already in place. See e. g.,
the adobe example in the non-free respo (devel branch)
If we do go down this path, I'd also suggest that we include a
README
file with each such package that clearly states:
- this is only a repo file
- it just points you to the repository hosted by the third party
- you're getting the software directly from the vendors repository
- it is only for convenience
- we cannot support bug/feature requests; they go upstream (or wherever)
- the source code of this software is not available. Please use at your
own risk, i.e., you trust the developer.
Perhaps. Or force user to accept use of the repo prior to usage. See
my previous reply to Hans and Ralph.
Lastly, we may need to speak to the third party devs and confirm if
it's
OK to ship their repo files in the first place?
Don't think this is a concern. Normally, there is an upstream manual
howto describing how to create this file, and if we automate this that
should not be an issue. If they offer public access to their repo that
should be enough IMHO.
Cheers!
--alec
[1] https://github.com/leamas/system-config-repo
1:14 a.m.
[2nd attempt to answer to this. My initial response from quite a while
age seems to have gone lost.]
On 01/29/2014 12:12 PM, Alec Leamas wrote:
Formally, this is about review request 3152 for dropbox-repo [1].
From
a more practical POV, it's about users being able to install software
like dropbox more or less "out of the box", an area where I think we
really need to improve (as can be seen in all those "Fedora XX post
installation guide" out there).
My basic understanding is that current Fedora guidelines needs a
interpretation in the rpmfusion context. Those brand new GL for 3-rd
party repos are in [2] (discussions in [3]). For now, I think they can
be abridged to:
- Non-free repos can not be part of Fedora yum configuration.
- In some cases free repos can be part of the configuration after
FESCO/Fedora legal approval.
Now, IMHO this doesn't really make much sense for rpmfusion for three reasons:
- rpmfusion does not ban non-free software, it's one of the very
reasons it exists.
- FESCO/Fedora legal cannot approve anything in rpmfusion.
- We already have a list of endorsed 3-rd party repos [4].
To handle this, my simple proposal is that we handles packaged yum
repositories like this:
- It's ok to package yum repositories listed in [4].
- If anyone wants to change the list in [4] this should be announced
here on rpmfusion-devel, and not done until we agree on it (similar to
how we handle bundling exceptions).
Thoughts. out there?
All in all, I am not OK with rpmfusion shipping other party's repos,
because such repos are out of Fedora's/Rpmfusion's control/influence.
They open up an arbitrary amount of opportunities for these 3rd parties
to break, corrupt and damage Fedora installations (Package conflicts,
low quality packages, malware, spyware, intruded/dead/broken 3rd party
servers, etc), without Fedora/RPMfusion being able to do anything
against it.
In other words, I'd recommend not doing so, because you guys are likely
to be facing very tough times in cases something goes wrong with these
"endorsed 3rd party repos".
Ralf
9:52 a.m.
Hi,
On 02/03/2014 02:14 AM, Ralf Corsepius wrote:
[2nd attempt to answer to this. My initial response from quite a
while age seems to have gone lost.]
On 01/29/2014 12:12 PM, Alec Leamas wrote:
> Formally, this is about review request 3152 for dropbox-repo [1]. From
> a more practical POV, it's about users being able to install software
> like dropbox more or less "out of the box", an area where I think we
> really need to improve (as can be seen in all those "Fedora XX post
> installation guide" out there).
>
> My basic understanding is that current Fedora guidelines needs a
> interpretation in the rpmfusion context. Those brand new GL for 3-rd
> party repos are in [2] (discussions in [3]). For now, I think they can
> be abridged to:
> - Non-free repos can not be part of Fedora yum configuration.
> - In some cases free repos can be part of the configuration after
> FESCO/Fedora legal approval.
>
> Now, IMHO this doesn't really make much sense for rpmfusion for three reasons:
> - rpmfusion does not ban non-free software, it's one of the very
> reasons it exists.
> - FESCO/Fedora legal cannot approve anything in rpmfusion.
> - We already have a list of endorsed 3-rd party repos [4].
>
> To handle this, my simple proposal is that we handles packaged yum
> repositories like this:
> - It's ok to package yum repositories listed in [4].
> - If anyone wants to change the list in [4] this should be announced
> here on rpmfusion-devel, and not done until we agree on it (similar to
> how we handle bundling exceptions).
>
> Thoughts. out there?
All in all, I am not OK with rpmfusion shipping other party's repos, because such
repos are out of Fedora's/Rpmfusion's control/influence.
They open up an arbitrary amount of opportunities for these 3rd parties to break, corrupt
and damage Fedora installations (Package conflicts, low quality packages, malware,
spyware, intruded/dead/broken 3rd party servers, etc), without Fedora/RPMfusion being able
to do anything against it.
In other words, I'd recommend not doing so, because you guys are likely to be facing
very tough times in cases something goes wrong with these "endorsed 3rd party
repos".
+1
Regards,
Hans
10:52 a.m.
On 02/03/2014 10:52 AM, Hans de Goede wrote:
Hi,
On 02/03/2014 02:14 AM, Ralf Corsepius wrote:
> [2nd attempt to answer to this. My initial response from quite a while
> age seems to have gone lost.]
>
> On 01/29/2014 12:12 PM, Alec Leamas wrote:
>> Formally, this is about review request 3152 for dropbox-repo [1]. From
>> a more practical POV, it's about users being able to install software
>> like dropbox more or less "out of the box", an area where I think we
>> really need to improve (as can be seen in all those "Fedora XX post
>> installation guide" out there).
>>
>> My basic understanding is that current Fedora guidelines needs a
>> interpretation in the rpmfusion context. Those brand new GL for 3-rd
>> party repos are in [2] (discussions in [3]). For now, I think they can
>> be abridged to:
>> - Non-free repos can not be part of Fedora yum configuration.
>> - In some cases free repos can be part of the configuration after
>> FESCO/Fedora legal approval.
>>
>> Now, IMHO this doesn't really make much sense for rpmfusion for three
>> reasons:
>> - rpmfusion does not ban non-free software, it's one of the very
>> reasons it exists.
>> - FESCO/Fedora legal cannot approve anything in rpmfusion.
>> - We already have a list of endorsed 3-rd party repos [4].
>>
>> To handle this, my simple proposal is that we handles packaged yum
>> repositories like this:
>> - It's ok to package yum repositories listed in [4].
>> - If anyone wants to change the list in [4] this should be announced
>> here on rpmfusion-devel, and not done until we agree on it (similar to
>> how we handle bundling exceptions).
>>
>> Thoughts. out there?
>
> All in all, I am not OK with rpmfusion shipping other party's repos,
> because such repos are out of Fedora's/Rpmfusion's control/influence.
>
> They open up an arbitrary amount of opportunities for these 3rd
> parties to break, corrupt and damage Fedora installations (Package
> conflicts, low quality packages, malware, spyware,
> intruded/dead/broken 3rd party servers, etc), without Fedora/RPMfusion
> being able to do anything against it.
>
> In other words, I'd recommend not doing so, because you guys are
> likely to be facing very tough times in cases something goes wrong
> with these "endorsed 3rd party repos".
+1
Regards,
Hans
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
12:07 p.m.
n 2/3/14, Xavier Bachelot <xavier(a)bachelot.org> wrote:
On 02/03/2014 10:52 AM, Hans de Goede wrote:
> Hi,
>
> On 02/03/2014 02:14 AM, Ralf Corsepius wrote:
>> [2nd attempt to answer to this. My initial response from quite a while
>> age seems to have gone lost.]
>>
>> On 01/29/2014 12:12 PM, Alec Leamas wrote:
>>> Formally, this is about review request 3152 for dropbox-repo [1]. From
>>> a more practical POV, it's about users being able to install software
>>> like dropbox more or less "out of the box", an area where I think
we
>>> really need to improve (as can be seen in all those "Fedora XX post
>>> installation guide" out there).
>>>[cut]
>>>
>>> To handle this, my simple proposal is that we handles packaged yum
>>> repositories like this:
>>> - It's ok to package yum repositories listed in [4].
>>> - If anyone wants to change the list in [4] this should be announced
>>> here on rpmfusion-devel, and not done until we agree on it (similar to
>>> how we handle bundling exceptions).
>>>
>>> Thoughts. out there?
>>
>> All in all, I am not OK with rpmfusion shipping other party's repos,
>> because such repos are out of Fedora's/Rpmfusion's control/influence.
>>
>> They open up an arbitrary amount of opportunities for these 3rd
>> parties to break, corrupt and damage Fedora installations (Package
>> conflicts, low quality packages, malware, spyware,
>> intruded/dead/broken 3rd party servers, etc), without Fedora/RPMfusion
>> being able to do anything against it.
Noone is arguing for "an arbitrary amount of opportunities" , at least
not I. My overall idea is still that the overall rule should be that
external repo packaging is forbidden. But, like for bundling, there
should be exceptions.
>> In other words, I'd recommend not doing so, because you
guys are
>> likely to be facing very tough times in cases something goes wrong
>> with these "endorsed 3rd party repos".
>
> +1
>
> Regards,
>
> Hans
This is a valid concern, although I don't think it should be enough to
block any packaging attempt.
We could change things so that the files are shipped in /usr/whatever
and only "activated" i. e., copied to /etc/yum.repos.d after some
kind of dialog where user accepts this (perhaps with a warning text
like above). Would this improve the situation?
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.
[cut]
From a poilicy point of view current Fedora guidelines on this (which
we should comply to ?!) is really more or less a full page about
conditions when packaging of external repositories is acceptable or
not. If rpmfusion should conclude not to package *any* repository,
this would be a (much?) more restrictive rule than current Fedora
guidelines. Is this reasonable?
As for legal spot has concluded that packaging a repository carries a
substantially smaller risk than repacking other parties sw (which is
what lpf is all about). Link in first post, discussions.
Practically, I feel that some of these arguments seems based on that
all external repos are equal. However, they differ a lot. Leaving the
list of "endorsed" repos aside (that list might very well be a Bad
Idea anyway), how does these arguments apply the dropbpox repo (which
only carries the leaf application dropbox). E. g., what's the risk
that this application would destabilize the overall system?
9:50 a.m.
On 02/03/2014 01:07 PM, Alec Leamas wrote:
n 2/3/14, Xavier Bachelot <xavier(a)bachelot.org> wrote:
> On 02/03/2014 10:52 AM, Hans de Goede wrote:
>> Hi,
>>
>> On 02/03/2014 02:14 AM, Ralf Corsepius wrote:
>>> [2nd attempt to answer to this. My initial response from quite a while
>>> age seems to have gone lost.]
>>>
>>> On 01/29/2014 12:12 PM, Alec Leamas wrote:
>>>> Formally, this is about review request 3152 for dropbox-repo [1]. From
>>>> a more practical POV, it's about users being able to install
software
>>>> like dropbox more or less "out of the box", an area where I
think we
>>>> really need to improve (as can be seen in all those "Fedora XX post
>>>> installation guide" out there).
>>>> [cut]
>>>>
>>>> To handle this, my simple proposal is that we handles packaged yum
>>>> repositories like this:
>>>> - It's ok to package yum repositories listed in [4].
>>>> - If anyone wants to change the list in [4] this should be announced
>>>> here on rpmfusion-devel, and not done until we agree on it (similar to
>>>> how we handle bundling exceptions).
>>>>
>>>> Thoughts. out there?
>>>
>>> All in all, I am not OK with rpmfusion shipping other party's repos,
>>> because such repos are out of Fedora's/Rpmfusion's
control/influence.
>>>
>>> They open up an arbitrary amount of opportunities for these 3rd
>>> parties to break, corrupt and damage Fedora installations (Package
>>> conflicts, low quality packages, malware, spyware,
>>> intruded/dead/broken 3rd party servers, etc), without Fedora/RPMfusion
>>> being able to do anything against it.
Noone is arguing for "an arbitrary amount of opportunities" ,
Well, I am.
Installation of rpms is performed by root, i.e. package installation is
maximum insecure, i.e. allowing any repository an expression of maximum
trust to a repository provider by each user.
=> Any arbitrary repository provider is granted 100% control over a
system == "an arbitrary amount of opportunities".
It's the reason why we tell users to only install from trusted sources
(== repositories) and not to pick up random packages from the net. It's
one of the key points which had assured safety of Linux over the years
and which makes *the* key difference to other OSes (esp. Win and Android).
It's this rationale, why I consider adding the idea to add 3rd parties
to Fedora or RPMFusion to be a truely stupid idea.
This is a valid concern, although I don't think it should be
enough to
block any packaging attempt.
We could change things so that the files are shipped in /usr/whatever
and only "activated" i. e., copied to /etc/yum.repos.d after some
kind of dialog where user accepts this (perhaps with a warning text
like above). Would this improve the situation?
Sightly - It would at least shift
responsibility to the user.
However it depends much on packaging details.
E.g. how do you want to copy with rpm file ownership on files below
/etc/yum.repos.d/*.repo and conflicts between such files being shipped
by upstream-rpms (rpmfusion, adobe do so), non-rpm-upstreams (e.g.
google-chrome does so) and manually written ones.
> 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.
Exactly. It is the selling point and the point behind telling people not
to use repositories which do not care about it (e.g. rpmforge or atrpms).
From a poilicy point of view current Fedora guidelines on this
(which
we should comply to ?!) is really more or less a full page about
conditions when packaging of external repositories is acceptable or
not.
Which page are you referring to? One of these recently written pages to
"embrace 3rd parties"?
My personal position is clear: A stupid idea, whose only purpose is
populism.
With my FPC head on: We do not allow 3rd party repos in Fedora, because
Fedora can't cope with them on the legal and on the technical sides.
In this light, as I understand, RPMFusion is trying to fill this gap.
Practically, I feel that some of these arguments seems based on that
all external repos are equal. However, they differ a lot. Leaving the
list of "endorsed" repos aside (that list might very well be a Bad
Idea anyway), how does these arguments apply the dropbpox repo (which
only carries the leaf application dropbox). E. g., what's the risk
that this application would destabilize the overall system?
As I said before, any
arbitrary package has all opportunities to comit
any possible kind of damage to your system - The set of possible
imaginable scenarios is infinite.
Ralf
8:24 p.m.
On 2/5/14, Ralf Corsepius <ralf.corsepius(a)gmail.com> wrote:
On 02/03/2014 01:07 PM, Alec Leamas wrote:
> n 2/3/14, Xavier Bachelot <xavier(a)bachelot.org> wrote:
>> On 02/03/2014 10:52 AM, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 02/03/2014 02:14 AM, Ralf Corsepius wrote:
>>>> [2nd attempt to answer to this. My initial response from quite a while
>>>> age seems to have gone lost.]
>>>>
>>>> On 01/29/2014 12:12 PM, Alec Leamas wrote:
>>>>> Formally, this is about review request 3152 for dropbox-repo [1].
>>>>> From
>>>>> a more practical POV, it's about users being able to install
software
>>>>> like dropbox more or less "out of the box", an area where I
think we
>>>>> really need to improve (as can be seen in all those "Fedora XX
post
>>>>> installation guide" out there).
>>>>> [cut]
>>>>>
>>>>> To handle this, my simple proposal is that we handles packaged yum
>>>>> repositories like this:
>>>>> - It's ok to package yum repositories listed in [4].
>>>>> - If anyone wants to change the list in [4] this should be announced
>>>>> here on rpmfusion-devel, and not done until we agree on it (similar
>>>>> to
>>>>> how we handle bundling exceptions).
>>>>>
>>>>> Thoughts. out there?
>>>>
>>>> All in all, I am not OK with rpmfusion shipping other party's repos,
>>>> because such repos are out of Fedora's/Rpmfusion's
control/influence.
>>>>
>>>> They open up an arbitrary amount of opportunities for these 3rd
>>>> parties to break, corrupt and damage Fedora installations (Package
>>>> conflicts, low quality packages, malware, spyware,
>>>> intruded/dead/broken 3rd party servers, etc), without Fedora/RPMfusion
>>>> being able to do anything against it.
>
> Noone is arguing for "an arbitrary amount of opportunities" ,
Well, I am.
Installation of rpms is performed by root, i.e. package installation is
maximum insecure, i.e. allowing any repository an expression of maximum
trust to a repository provider by each user.
=> Any arbitrary repository provider is granted 100% control over a
system == "an arbitrary amount of opportunities".
It's the reason why we tell users to only install from trusted sources
(== repositories) and not to pick up random packages from the net. It's
one of the key points which had assured safety of Linux over the years
and which makes *the* key difference to other OSes (esp. Win and Android).
Agreed.
But we are not talking about random packages from the net. We
are talking about making it easy to install specific apps from some
selected repos.
It's this rationale, why I consider adding the idea to add 3rd
parties
to Fedora or RPMFusion to be a truely stupid idea.
Could you not at least agree on
that we actually have a trade-off
here? Many (most? almost all?) fedora/rpmfusion users want to use some
apps available from 3-rd party repos for various reasons. Not
supporting this at all forces them to apply random guides out there,
with all sorts of risks and problems. Supporting it also carries
risks, agreed. But I just don't think it's fair to call any position
about this "stupid".
> This is a valid concern, although I don't think it should be
enough to
> block any packaging attempt.
>
> We could change things so that the files are shipped in /usr/whatever
> and only "activated" i. e., copied to /etc/yum.repos.d after some
> kind of dialog where user accepts this (perhaps with a warning text
> like above). Would this improve the situation?
Sightly - It would at least shift responsibility to the user.
As of today, user
will face the dialog in [1]. This would IMHO make
user responsible.
However it depends much on packaging details.
E.g. how do you want to copy with rpm file ownership on files below
/etc/yum.repos.d/*.repo and conflicts between such files being shipped
by upstream-rpms (rpmfusion, adobe do so), non-rpm-upstreams (e.g.
google-chrome does so) and manually written ones.
As for dropbox-repo, the repo file is in a sub-package. The main
package requires the repo file directly. The result is that it will
use an already existing repo file without conflicts, more or less
just adding some metadata to it.
> From a poilicy point of view current Fedora guidelines on this
(which
> we should comply to ?!) is really more or less a full page about
> conditions when packaging of external repositories is acceptable or
> not.
Which page are you referring to? One of these recently written pages to
"embrace 3rd parties"?
My personal position is clear: A stupid idea, whose only purpose is
populism.
If populism is about making Fedora/rpmfusion a popular distribution,
then call me a populist. I can live with that.
With my FPC head on: We do not allow 3rd party repos in Fedora,
because
Fedora can't cope with them on the legal and on the technical sides.
Reading
current GL I cannot interpret them as a plain "We do not allow
3rd party repos in Fedora". If the rule was that simple, why a full
page of text with different cases?
From a technical POV, I cannot see the difficulties in adding a repo
file. Am I missing something here?
That said, of course much of these GL is about legal issues. As this
is where rpmfusion really differs, we certainly need to understand
what these GL means for rpmfusion. The current request complies to the
following to cope with the risks:
- User must enable it manually, after a disclaimer warning, as
required in the GL.
- The enabled repository is a "specific piece of free software"
according the the GL, besides being non-free.
- The repo file uses gpg verification and also a includepkgs=
condition to only enable the dropbox application.
To my understanding, taken together these conditions complies to the
current GL, interpreted in a rpmfusion context where we use handle
non-free software.
But in the end this is probably about a vision. rpmfusion.org states
that it's about "simplify end-user experience by grouping as much
add-on software as possible in a single location". In my eyes, making
it possible to install the dropbox client fits well into this.
Cheers!
--alec
[1] https://github.com/leamas/system-config-repo/blob/devel/screenshots/0-act...
12:28 p.m.
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
9:03 p.m.
Hi!
On 03.02.2014 10:52, Hans de Goede wrote:
On 02/03/2014 02:14 AM, Ralf Corsepius wrote: [...]
> In other words, I'd recommend not doing so, because you guys are
> likely to be facing very tough times in cases something goes
> wrong with these "endorsed 3rd party repos".
+1
RPM Fusion is something most Fedora users will enable, so IMHO it's
the ideal place to give users something at hand to reach software that
can't be in Fedora or RPM Fusion for various reasons â flash player
for example.
Packages with repo files otoh might not be best way. I guess the best
way forward would be a small app that points out the risks and
explains that RPM Fusion is not responsible for content from other
repos; if the users ACks that let the app put repo file in place.
Just my 2 cent because I always wanted something like the above. Ohh,
and because my name came up recently in this discussion, as one of
those that was (is?) considered to be on the (inactive) RPM Fusion
steering committee. Might be wise to set up a new one. I'm fine if
those that are most active simply organize something and put it in
place, you have my blessing. If that's not enough: if you want a
official vote or something else from me just let me know when and
where to give what's needed ;-)
Cu
knurd
9:30 p.m.
Hi,
On 02/03/2014 10:03 PM, Thorsten Leemhuis wrote:
Hi!
On 03.02.2014 10:52, Hans de Goede wrote:
> On 02/03/2014 02:14 AM, Ralf Corsepius wrote: [...]
>> In other words, I'd recommend not doing so, because you guys are
>> likely to be facing very tough times in cases something goes
>> wrong with these "endorsed 3rd party repos".
> +1
RPM Fusion is something most Fedora users will enable, so IMHO it's
the ideal place to give users something at hand to reach software that
can't be in Fedora or RPM Fusion for various reasons â flash player
for example.
Packages with repo files otoh might not be best way. I guess the best
way forward would be a small app that points out the risks and
explains that RPM Fusion is not responsible for content from other
repos; if the users ACks that let the app put repo file in place.
Just my 2 cent because I always wanted something like the above. Ohh,
and because my name came up recently in this discussion, as one of
those that was (is?) considered to be on the (inactive) RPM Fusion
steering committee. Might be wise to set up a new one. I'm fine if
those that are most active simply organize something and put it in
place, you have my blessing. If that's not enough: if you want a
official vote or something else from me just let me know when and
where to give what's needed ;-)
+1 to all of the above, I too am fine with some app to enable
additional repos or some such, I just don't like any form of
"yum install" automatically enabling new out of our control
repos.
Regards,
Hans
10:04 p.m.
On 2/3/14, Hans de Goede <j.w.r.degoede(a)gmail.com> wrote:
Hi,
On 02/03/2014 10:03 PM, Thorsten Leemhuis wrote:
> Hi!
>
> On 03.02.2014 10:52, Hans de Goede wrote:
>> On 02/03/2014 02:14 AM, Ralf Corsepius wrote: [...]
>>> In other words, I'd recommend not doing so, because you guys are
>>> likely to be facing very tough times in cases something goes
>>> wrong with these "endorsed 3rd party repos".
>> +1
>
> RPM Fusion is something most Fedora users will enable, so IMHO it's
> the ideal place to give users something at hand to reach software that
> can't be in Fedora or RPM Fusion for various reasons â EURO " flash player
> for example.
On a sidenote, flash is already available as lpf-flash-plugin. But
that's another story.
> Packages with repo files otoh might not be best way. I guess the
best
> way forward would be a small app that points out the risks and
> explains that RPM Fusion is not responsible for content from other
> repos; if the users ACks that let the app put repo file in place.
>
> Just my 2 cent because I always wanted something like the above. Ohh,
> and because my name came up recently in this discussion, as one of
> those that was (is?) considered to be on the (inactive) RPM Fusion
> steering committee. Might be wise to set up a new one. I'm fine if
> those that are most active simply organize something and put it in
> place, you have my blessing. If that's not enough: if you want a
> official vote or something else from me just let me know when and
> where to give what's needed ;-)
+1 to all of the above, I too am fine with some app to enable
additional repos or some such, I just don't like any form of
"yum install" automatically enabling new out of our control
repos.
Regards,
Hans
Hi,
+1 also from me. I'll update system-config-repo to handle packaged
repos in a way forcing user to confirm the actual copying to
/etc/yum.repos.d before it's done. Shouldn't be a big deal, I've had
it in mind while hacking it up.
To clarify, this means that also I agree on that some magic enabling
of an external repo just by installing a package isn't really a good
idea.
Unless there is more input in this thread I will update
system-config repo and make corresponding changes to my review
request. Then we'll see if someone has the nerves the actually do the
review :)
Thanks for all input!
Cheers,
--alec
8:42 a.m.
On 02/03/2014 11:04 PM, Alec Leamas wrote:
On 2/3/14, Hans de Goede <j.w.r.degoede(a)gmail.com> wrote:
> Hi,
>
> On 02/03/2014 10:03 PM, Thorsten Leemhuis wrote:
>> Hi!
>>
>> On 03.02.2014 10:52, Hans de Goede wrote:
>>> On 02/03/2014 02:14 AM, Ralf Corsepius wrote: [...]
>>>> In other words, I'd recommend not doing so, because you guys are
>>>> likely to be facing very tough times in cases something goes
>>>> wrong with these "endorsed 3rd party repos".
>>> +1
>>
>> RPM Fusion is something most Fedora users will enable, so IMHO it's
>> the ideal place to give users something at hand to reach software that
>> can't be in Fedora or RPM Fusion for various reasons â EURO " flash
player
>> for example.
On a sidenote, flash is already available as lpf-flash-plugin. But
that's another story.
>> Packages with repo files otoh might not be best way. I guess the best
>> way forward would be a small app that points out the risks and
>> explains that RPM Fusion is not responsible for content from other
>> repos; if the users ACks that let the app put repo file in place.
>>
>> Just my 2 cent because I always wanted something like the above. Ohh,
>> and because my name came up recently in this discussion, as one of
>> those that was (is?) considered to be on the (inactive) RPM Fusion
>> steering committee. Might be wise to set up a new one. I'm fine if
>> those that are most active simply organize something and put it in
>> place, you have my blessing. If that's not enough: if you want a
>> official vote or something else from me just let me know when and
>> where to give what's needed ;-)
>
> +1 to all of the above, I too am fine with some app to enable
> additional repos or some such, I just don't like any form of
> "yum install" automatically enabling new out of our control
> repos.
>
> Regards,
>
> Hans
Hi,
+1 also from me. I'll update system-config-repo to handle packaged
repos in a way forcing user to confirm the actual copying to
/etc/yum.repos.d before it's done. Shouldn't be a big deal, I've had
it in mind while hacking it up.
To clarify, this means that also I agree on that some magic enabling
of an external repo just by installing a package isn't really a good
idea.
+1 for system-config-repo, user interaction is much better than silent
enablement of repositories on package installation. I would just like a
feature to remove all packages coming from a given repo when it is
disabled by the user, in order not to left installed packages that will
not receive (security) updates anymore.
Also, iirc, some repos are providing packages with known security flaws.
While some users might need these repo/software for good or bad reasons,
they should be warned to be extra careful. I'm thinking of AcrobatReader
here, but there might be others.
Unless there is more input in this thread I will update
system-config repo and make corresponding changes to my review
request. Then we'll see if someone has the nerves the actually do the
review :)
Thanks for all input!
Cheers,
--alec
Regards,
Xavier
9:39 a.m.
On 2/4/14, Xavier Bachelot <xavier(a)bachelot.org> wrote:
+1 for system-config-repo, user interaction is much better than silent
enablement of repositories on package installation. I would just like a
feature to remove all packages coming from a given repo when it is
disabled by the user, in order not to left installed packages that will
not receive (security) updates anymore.
Although a good idea it's not trivial since it's to too much to put
into a scriptlet. The best for now is probably if you file a bug at
system-config-repo upstream [1].
Also, iirc, some repos are providing packages with known security
flaws.
While some users might need these repo/software for good or bad reasons,
they should be warned to be extra careful. I'm thinking of AcrobatReader
here, but there might be others.
Basically, this should come up if/when someone submits a review
request for this repo. I plan to show some text before enabling a
repo, and this text is not generic. So there will be hooks to enter
whatever warning(s) we want to give.
Cheers!
--alec
[1} https://github.com/leamas/system-config-repo/
2:05 p.m.
Hi,
On Qua, 2014-01-29 at 12:12 +0100, Alec Leamas wrote:
Formally, this is about review request 3152 for dropbox-repo [1].
From
a more practical POV, it's about users being able to install software
like dropbox more or less "out of the box", an area where I think we
really need to improve (as can be seen in all those "Fedora XX post
installation guide" out there).
My basic understanding is that current Fedora guidelines needs a
interpretation in the rpmfusion context. Those brand new GL for 3-rd
party repos are in [2] (discussions in [3]). For now, I think they can
be abridged to:
- Non-free repos can not be part of Fedora yum configuration.
- In some cases free repos can be part of the configuration after
FESCO/Fedora legal approval.
Now, IMHO this doesn't really make much sense for rpmfusion for three reasons:
- rpmfusion does not ban non-free software, it's one of the very
reasons it exists.
- FESCO/Fedora legal cannot approve anything in rpmfusion.
- We already have a list of endorsed 3-rd party repos [4].
To handle this, my simple proposal is that we handles packaged yum
repositories like this:
- It's ok to package yum repositories listed in [4].
- If anyone wants to change the list in [4] this should be announced
here on rpmfusion-devel, and not done until we agree on it (similar to
how we handle bundling exceptions).
Thoughts. out there?
hum unfortunately I don't had much time for this subject , I don't read
carefully all thread, going straight to the point I think you could use
yumex instead the tool you are making (I don't find name right now) to
manage repos.
But I'd like to insist in putting a system depends on 3rd party repos
(adding 3rd party repos) is bad, and I prefer a solution like a proxy
repo that we talk in package review [1].
Almost all 3rd party repos don't have mirrors. Recently when
download1.rpmfusion.org was down (for a moment, in that moment ) yum
hanged for very long time and doesn't update anything . So if a 3rd
party repo goes down yum update will fail . If a 3rd party repo is very
slow yum update will be very slow . Maybe in yum.conf for this 3rd party
repos use skip_if_unavailable=True
https://bugzilla.rpmfusion.org/show_bug.cgi?id=3152#c30
--
Sérgio M. B.
3949
days inactive
3984
days old
rpmfusion-developers@lists.rpmfusion.org
19 comments
9 participants
participants (9)
-
Alec Leamas -
Andrea Musuruane -
Ankur Sinha -
Hans de Goede -
Ralf Corsepius -
Sérgio Basto -
Thorsten Leemhuis -
Till Maas -
Xavier Bachelot