Raphaël Hertzog: Official Debian/Ubuntu packages for Dropbox
Dropbox is a popular service to synchronize files between multiple computers. The service is entirely proprietary but the company is Linux friendly and provides Linux binaries ready to use. They even provide Ubuntu packages that wrap the dropbox client and provide integration with Nautilus.
A bit of story
Unfortunately for Debian users, those packages do not work on Debian due to a dependency that can t be satisfied (because Ubuntu introduced an epoch on the version of their nautilus package that Debian doesn t have). This was even reported in a Squeeze review in Linux Weekly News.
At some point, Ivan Borzenkov introduced a dropbox package to Debian but it was not based on the above package, instead it packaged directly the proprietary binaries. This was a bad decision because the binaries bundle a set of LGPL libraries and nobody from Debian wanted to do the required work to provide the corresponding source code. So the package got dropped (see bug #610300).
More recently several persons filed ITP (Intent To Package) bugs stating their willingness to re-introduce dropbox in Debian, but after many months lingering in the bug tracking system (see #544499, #613788), they have been turned back to RFP (Request For Package) because they changed their minds.
What I did
Being a dropbox user myself (despite the recent proof that data stored on dropbox is not 100% private), I offered sponsorship to the volunteers who wanted to package dropbox. But it turns out this was not enough to motivate someone to complete the task.
In the mean time I was still using the old dropbox package that was removed (it used to be downloadable from snapshot.debian.org).
While this was good enough for me, it s clearly not OK in the long term and way too difficult for the majority of users. So this week-end I spent some hours to create a proper package.
It s loosely based on the package provided by Dropbox but I upgraded the packaging and changed the way it works. I patched the dropbox wrapper to provide a dropbox update command that downloads and updates the proprietary binaries. They are now stored in /var/lib/dropbox instead of having a copy in each user s home directory (~/.dropbox-dist/). This update command is run by the postinst so that installing the package immediately downloads the proprietary binaries.
Get the Dropbox packages for Debian
The package nautilus-dropbox has been uploaded to Debian unstable,apt-get install nautilus-dropbox (provided that you activated the non-free section since that s where the package is hosted, it can t be part of Debian since it requires the proprietary binaries to be useful).
In the mean time you can get the packages from the links below:
- For Debian Squeeze: i386 amd64
For Debian unstable/wheezy: i386 amd64For Debian unstable with GNOME3 from experimental: i386 amd64
$ sudo add-apt-repository ppa:hertzog/nautilus-dropbox $ sudo apt-get update $ sudo apt-get install nautilus-dropboxIt also includes packages for oneiric, but in theory once the package is accepted into Debian, it should appear in oneiric shortly after. Package maintenance I have done the initial packaging work but I don t really want to maintain it in the long term. I have more than enough to do with dpkg and my other packages. So if you are interested in maintaining this package, please get in touch with me. You should know a bit of python since there are Debian-specific patches of the upstream code. The package is maintained in a git repository. Feedback If you have encountered a problem with one of those packages, feel free to leave a comment. If you re an happy user of the above packages, click here to find out how you can thank me. I hope you enjoy the packages!
13 comments Liked this article? Click here. My blog is Flattr-enabled.
On June 8, 2011, will be
I'm trying to resume some activity in OSM maintenance.
As many people, I mapped most parts ofmy neighbourhood, as one can see
when looking at 




As I write this, it's the morning of June 5th, 1981. A few people scattered
across the US are waking up, going in to work, sitting down at their terminal
with a coffee, and reading Usenet. Usenet is only getting a trickle of posts
each day -- it's still in that period where it's easy to read every message
posted to it.
Many things lie in Usenet's future. It's still running
and it starts with f
While looking at the future of the KDE
Hello, this is the official project report for the Debian GSoC admins and everyone. It s been few days since the official coding phase started. Most of the time I ve been figuring out the details regarding integration of non-x86 images to the Eucalyptus IaaS and working on the ARM image, as you ll learn later. I m also in the process of starting to design the set of tools we ll be delivering as part of the project.
The project s goal is to be a useful resource for Debian developers and porters. I ve joined some porters list in order to learn what are the things they are struggling with and how the project can help to address them. I ll be starting a wiki page with such topics.
Bonding period:
DECLARATIVE DIVERSIONS
======================
Introduction
A diversion is when it is possible to have dpkg not overwrite a file when it
reinstalls the package it belongs to, and to have it put the file from the
package somewhere else instead.
Declarative diversions involves a new control file with a declarative
syntax which dpkg will parse and process directly as part of the package unpack
and removal phases, eliminating the problems resulting from non-atomic
handling of diversions.
Topics
There are a number of topics involved in implementing this kind of project
* What syntax do we use for the new control file?
* What dpkg does with the control file
* How do we handle diversions to a non-existant directory?
* How do we order unpacking a new package which adds a diversion?
* How do we order unpacking a new package that removes a diversion?
* How do we order removing a package which had a diversion?
* How do we handle errors?
* What happens to dpkg-divert?
-
Details - Control File Syntax
-
It will conform to RFC2822 style with the following format:
* Divert-From:
* Divert-To:
* Blank lines and lines beginning with # will be comments
Divert-To will be optional and if it is ommitted then files being diverted
will have their filename changed to file.distrib
The above style has it s advantages, one of the main ones being that there is
no need to escape whitespace within filenames.
-
Details - Control File Handling
-
Within control.tar.gz the file should be named diversions
This file is then copied to /var/lib/info/$package.diversions
This is ensuring we have a copy of the control file just in case it is needed.
Any input on this subject would be appreciated.
-
Details - Handling Diversions to non-existant directories
-
Diverting files to directories that don t exist can cause a number of problems.
If the package does not own the directory it may be left orphaned on
removal of the package
The package is responsible for ensuring the availability of the target directory in the unpack phase.
-
Details - Ordering Requirements
-
=>Unpacking a new package that adds a diversion
*1. Unpack folders
*2. Add diversions
*3. Unpack files
==Notes==
Performing diversions this way avoids trouble with creating folders and
accidentally overwrtiting the wrong version of files.
If we don t use this method the problems that can occur include creating
folders before the package itself would create them which may cause
permission errors.
Another major problem would be extracting a new version of the file and
overwriting the old one.
This might cause the wrong version of the file to be diverted and the
package to break.
=>Unpacking a new package that removes a diversion
*1. Unpack folders
*2. Add diversions
*3. Unpack files
==Notes==
=>Removing a package which had a diversion
*1. Remove files
*2. Remove diversions
*3. Remove folders
==Notes==
This ensures that all files, diversions and folders are removed correctly
Details - Error handling
Errors in diversions will have to handled with a great deal of care due to
the fact that if they are not the package could be broken.
This means that a great deal of checks must be done to ensure that all the files
can be diverted properly before any actual diverting takes place. If they can t
the package installation/update must be stopped and rolled back to avoid the
package being installed incorrectly or broken.
-
Details - dpkg-divert
-
When we impliment the new diversion method we should keep the current
dpkg-divert. This allows maintainers to catch up with the new method without
breaking their packages. It also allows maintainers to perform some operations
that aren t support by the new method.
Example Usage #1
The file to be diverted is /usr/share/foo
It needs to be moved to /usr/share/bar
The syntax of the control file would be:
#Start File
Divert-From: /usr/share/foo
Divert-To: /usr/share/bar
#End File
Example Usage #2
In this example the maintainer doesn t want to move the file to any specific
folder
The syntax of the control file would be:
#Start File
Divert-From: /usr/share/foo
#End File
This would divert the file to /usr/share/foo.distrib
-
Footnotes
-
RFC2822 Guide:
*
I have been
Doing some work towards Debian Rolling
At the start of the month, the discussions about Debian rolling were still very active on debian-devel. Declaring that testing would be rolling did not make it (as
So I just read that 


The increasing number of facebook "friends".
Apparently I have 113 "friends" in facebook.
So far I don't think I have seen any interesting things happening within facebook.
I saw a breakdown when my mixi contacts exceeded 100 people, and I started deleting stale connections. I don't know who to delete in facebook because I only been approving people whom I know in facebook, unlike in mixi where I used to become Friends as if it was a routine ritual in tech conferences.