Re: Packaging 3-rd party repositories in rpmfusion
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 --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 -- Sérgio M. B.
Re: Packaging 3-rd party repositories in rpmfusion
On 03/05/2014 08:05 AM, Sérgio Basto wrote: 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 +1, skip_if_unavailable=True should be a prerequisite to any added 3rd-party repos -- Rex
Re: Packaging 3-rd party repositories in rpmfusion
On 3/5/14, Rex Dieter rdie...@math.unl.edu wrote: On 03/05/2014 08:05 AM, Sérgio Basto wrote: 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 +1, skip_if_unavailable=True should be a prerequisite to any added 3rd-party repos -- Rex Agreed, will fix before importing. Nice catch! --alec
Re: Packaging 3-rd party repositories in rpmfusion
On 02/03/2014 01:07 PM, Alec Leamas wrote: n 2/3/14, Xavier Bachelot xav...@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
Re: Packaging 3-rd party repositories in rpmfusion
On 2/5/14, Ralf Corsepius ralf.corsep...@gmail.com wrote: On 02/03/2014 01:07 PM, Alec Leamas wrote: n 2/3/14, Xavier Bachelot xav...@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
Re: Packaging 3-rd party repositories in rpmfusion
On 02/03/2014 11:04 PM, Alec Leamas wrote: On 2/3/14, Hans de Goede j.w.r.dego...@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
Re: Packaging 3-rd party repositories in rpmfusion
On 2/4/14, Xavier Bachelot xav...@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/
Re: Packaging 3-rd party repositories in rpmfusion
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
Re: Packaging 3-rd party repositories in rpmfusion
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
Re: Packaging 3-rd party repositories in rpmfusion
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
Re: Packaging 3-rd party repositories in rpmfusion
n 2/3/14, Xavier Bachelot xav...@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?
Re: Packaging 3-rd party repositories in rpmfusion
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
Re: Packaging 3-rd party repositories in rpmfusion
On 2/3/14, Xavier Bachelot xav...@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
Re: Packaging 3-rd party repositories in rpmfusion
On 2/3/14, Ankur Sinha sanjay.an...@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
Re: Packaging 3-rd party repositories in rpmfusion
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
Re: Packaging 3-rd party repositories in rpmfusion
On 2/3/14, Hans de Goede j.w.r.dego...@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
Re: Packaging 3-rd party repositories in rpmfusion
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 signature.asc Description: This is a digitally signed message part
Re: Packaging 3-rd party repositories in rpmfusion
[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
Re: Packaging 3-rd party repositories in rpmfusion
On Wed, Jan 29, 2014 at 12:12 PM, Alec Leamas leamas.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.
Re: Packaging 3-rd party repositories in rpmfusion
On 1/29/14, Andrea Musuruane musur...@gmail.com wrote: On Wed, Jan 29, 2014 at 12:12 PM, Alec Leamas leamas.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
