[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 #29 from Sérgio Basto <sergio at serjux.com> 2014-01-27 23:57:42 CET ---
(In reply to comment #9)

> Sorry, too quick an answer from me. Dropbox is not re-distributble. The thing
> is just that the dropbox packages as provided by Dropbox are perfectly good to
> use as-is. What lpf is designed to do is to scope with is a situation like
> Spotify (no fedora rpm package) or flash-plugin (poorly packaged). In these
> cases, lpf can build a new package from what's available upstream. IMHO, this
> does not really apply to the dropbox case.

"lpf can build a new package from what's available upstream", and can use old
package from upstream and will be a little more direct no ? 

I'm thinking about if lpf can update automatically the version that upstream
give to us ...


> Also note the maintenance situation: for a lpf package: each new upstream
> release must be reflected in the lpf package. This is actually often a lot to
> do and is not something you choose unless there is no other option. 
> 
> Yes, there is a performance penalty on using other repositories. However, a
> repo like dropbox really seldom changes, so it's more a quick check. In the big
> picture, I think it's the right thing to do, as long as Dropbox don't change
> their terms.

Correct , so we have 2 points, one good and one bad, and I don't know which one
have more weight. 

I do know, for example, adobe Acrobat reader repo, was very very slow ,
hopefully now I don't use it for more than two years. I have used okular .  

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.

-- 
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.