https://bugzilla.rpmfusion.org/show_bug.cgi?id=3152
--- Comment #38 from Sérgio Basto <ser...@serjux.com> 2014-01-29 08:56:22 CET --- (In reply to comment #30) > (In reply to comment #29) > > (In reply to comment #9) > > > > > > > Conclusion an extend lpf for this situation, for me, is the best choice. The > > truth I don't have many time to investigate this and propose one solution. > > OK, I finally understand your reasoning. Putting lpf aside, let's assume we > make another tool for this situation called foreign-repo-proxy (frp). What > would such a tool actually do? > > - You could install some kind of proxy package e. g., frp-dropbox. > - That package would contain the repo description + package name. > - Something like 'frp install dropbox' would download the package(s) from the > repo and install it. > - Something like 'frp-update dropbox' would update the package(s) using the > repo. > > > It's doable, but is it worth it? > - Although we comply with the GL, do we really comply with the intentions(?) > - Yet another layer of tools for he user. A little better if merged into lpf, > but then that tool will become harder to grasp. > - As with lpf, there is dependency problems. This can be seen as an advantage > (nothing depends on foreign package) or a drawback for the same reason. > - Done correctly, there should be no need to update the frp package to reflect > upstream updates. We will not build the package, just download it. > - Upstream package changes (new packages etc.) will require new or updated > frp- > packages. > > Above all, this is added complexity compared to the simple "add-a-repo" > approach. This is also somehow the way accepted out there: Ubuntu PPA:s, COPR > repos etc. To communicate the need to make much more complicated frp-/lpf- > packages instead might be tough. So, I still want to test the "add-a-repo" > approach, if it's possible due to legal/policy concerns. > > Bottom line: we need to give user access to tools like dropbox in a much more > streamlined way. Not being able to install this kind of stuff more or less out > of the box is a major drawback. While I respect the reasons this is not viable > in Fedora, my gut feeling is that rpmfusion should allow it. yeah , one frp, with frp one user, in his system, have to force download an no-distributable package. lpc and frp could have same gui , but different modules. frp just check if repo have new stuff and update info to user, which may download it, could have notifications and auto-update . I don't see too much complication since we could use repoquery to foreign repo, give the information and manage installation . Less legal/policy concerns but will give more work to develop. what you mean with "Although we comply with the GL" ? about upstream package changes, don't think we need updated frp-packages, if work like a foreign-repo-proxy . if I have time in future I'll will try do frp idea, as a sub project of lpf :) Thanks, -- Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are the assignee for the bug.