[packagers] problems with dropbox package

Steve Huff shuff at vecna.org
Wed May 12 15:28:30 CEST 2010

(moved from the users list)

On May 11, 2010, at 9:49 PM, Dag Wieers wrote:

> I have made a rebuild which will only be available in 24 hours, but I looked at the package and I don't like it. Libraries should not go in /usr/libexec/dropbox and the python eggdrops should not be tagged as build against python 2.5 on RHEL5.
> Did anyone look at the license for redistributing dropbox ?

Dropbox is a mix of proprietary and FOSS code; the Nautilus integration component is GPL, and the dropboxd component is proprietary.  only a binary distribution is available (and I didn't have much luck getting the Nautilus integration component to build on el5, given that it's written for Python 2.5; i spent some time trying to backport it, but no joy).  on the other hand, the Dropbox client is freely downloadable; it's useless without the service.

as written, the Dropbox client for linux wants to install its binaries and shared libraries in ~/.dropbox.  this seemed silly on a multiuser system, so i moved them into /usr/libexec/dropbox; i wanted them to be somewhere that's generally not in a $PATH and where the linker wouldn't find them.  really, nothing should be linking against them except the dropbox binaries.

this project grew out of a work assignment, and i figured i'd share the results with RPMforge as i progressed.  there are still bugs (i tried to make that clear in the SVN log).  i'm open to suggestions at the macro or micro level :)


If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <http://lists.repoforge.org/pipermail/packagers/attachments/20100512/9c65c23f/attachment.sig>

More information about the packagers mailing list