[Bug 3152] Review request: dropbox-repo - 3rd-party repo package for Dropbox client

[RPM Fusion Bugzilla]

https://bugzilla.rpmfusion.org/show_bug.cgi?id=3152

--- Comment #38 from Sérgio Basto <sergio at 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.