Child Item

Linux install - do not add "dropbox.list" to apt... (deb)

Linux install - do not add "dropbox.list" to apt... (deb install) latest Linux versions use DEB822 Source Format now (.sources) or replace "dropbox.list" with "dropbox.surces"

example:

Types: deb
URIs: http://linux.dropbox.com/ubuntu/
Suites: questing
Components: main
Signed-By: /etc/apt/trusted.gpg.d/dropbox.asc

Find more posts tagged with

Desktop

Install

Linux

Insightful

Accepted answers

Neal

Hi @Verwijs,

Thanks for submitting your idea.

I've looked into this and it looks like we won't be implementing this as we have a built in command which will convert dropbox.list to dropbox.sources.

We appreciate the feedback though and are always looking to hear your feedback!

All comments

Здравко

Despite there is no due date for the old format (not yet at least), it's good idea update to be performed on time! 👍

More information: here and here for instance.

Neal

Hi @Verwijs,

Thanks for submitting your idea.

I've looked into this and it looks like we won't be implementing this as we have a built in command which will convert dropbox.list to dropbox.sources.

We appreciate the feedback though and are always looking to hear your feedback!

Здравко

Neal wrote:
... we have a built in command which will convert dropbox.list to dropbox.sources.

Hi @Neal,

I don't know what kind of command you have built, but your install still produces the old format. I just checked from the download page and select the newest deb file there. This file produces the old format still. The script (postinst) designed to install that information, residing there, is still the same (just a subset of that file I just downloaded):

....
REPOCONFIG="deb [arch=i386,amd64 signed-by=/etc/apt/keyrings/dropbox.asc] http://linux.dropbox.com/$DISTRO $REPO main"

          APT_GET="`which apt-get 2> /dev/null`"
          APT_CONFIG="`which apt-config 2> /dev/null`"

          # Parse apt configuration and return requested variable value.
          apt_config_val() {
            APTVAR="$1"
            if [ -x "$APT_CONFIG" ]; then
              "$APT_CONFIG" dump | sed -e "/^$APTVAR /"'!d' -e "s/^$APTVAR \"\(.*\)\".*/\1/"
            fi
          }

          # Set variables for the locations of the apt sources lists.
          find_apt_sources() {
            APTDIR=$(apt_config_val Dir)
            APTETC=$(apt_config_val 'Dir::Etc')
            APT_SOURCESDIR="$APTDIR$APTETC/$(apt_config_val 'Dir::Etc::sourceparts')"
          }

          # Add the Dropbox repository to the apt sources.
          # Returns:
          # 0 - no update necessary
          # 1 - sources were updated
          # 2 - error
          update_sources_lists() {
            if [ ! "$REPOCONFIG" ]; then
              return 0
            fi

            find_apt_sources

            if [ -d "$APT_SOURCESDIR" ]; then
              # Nothing to do if it's already there.
              SOURCELIST=$(grep -H "$REPOCONFIG" "$APT_SOURCESDIR/dropbox.list" \
                2>/dev/null | cut -d ':' -f 1)
              if [ -n "$SOURCELIST" ]; then
                return 0
              fi

              printf "$REPOCONFIG\n" > "$APT_SOURCESDIR/dropbox.list"
              if [ $? -eq 0 ]; then
                return 1
              fi
            fi
            return 2
          }
....

As you can see, nothing changed! This is the install script part that has to be adapted.

By the way, the last line of @Verwijs's example in OP is bad idea to be kept too. When possible (i.e. the sign is used for single repository only - that's the Dropbox case), it's advisable the sign to be embedded in the .source file (something impossible in .list) - so instead of 2 files (dropbox.asc and dropbox.list) will be enough only 1 (dropbox.source) and this is considered more secure.

All the best!

Neal

Apologies @Здравко!

I misspoke, the one-line call is built into apt, not Dropbox:

sudo apt modernize-sources

I did some research into this format, and while Debian using it by default is new, it will still work with every version of Debian and Ubuntu we support.

Здравко

Neal wrote:
I did some research into this format, and while Debian using it by default is new, it will still work with every version of Debian and Ubuntu we support.

Yes, it is valid still and will be to year 2029 at least (as described in documentation you have research did on). After that, despite not fixed yet when, the format may be stopped at any one moment. By the way, many other companies (like Microsoft, Oracle, etc.) have already moved their packages format to the new one. It's still not something urgent, but like many other things Dropbox will wait till old format becomes officially deprecated and dropped. 🤷 (i.e. when it comes up as something urgent)
And not only Debian uses it and it's not something new - Ubuntu uses it for ~3 years already as well as all other derivative distributions (check on all standard Ubuntu repositories 🙂 - can you see some .list there?!; I hope you wont check some too old unsupported release).

I hope you (Dropbox) won't rely users use any external commands (external to Dropbox) for Dropbox bugs fix! (including the one you posted) Would be a good idea Dropbox to "modernize" its packages, so additional modernization wouldn't be needed.

Neal

Hi again @Здравко!

This is the feedback I absolutely love to see on the Community!

I totally get it, addressing it before it becomes an issue and create less steps for the user. I've shared this thread and your detailed explanation with our team that handles Dropbox for Linux.

Hopefully this can be updated soon!

Здравко

Hi @Neal,

I want to report something little more urgent related again to your repository organization. I just tried to update my packages and found out that there is a bug in your repository (files size mismatch). In your repository the sign file (actually all 'InRelease' files), for 2 of the files there, is declared incorrect size and so apt refuses to update package data for Dropbox. You may take a look on and compare InRelease and Release files. For InRelease, I enlightened following:

...
 137ac6101594668cfdb4bd6c3845c9aa             2030 main/binary-amd64/Packages
 62674c968547a6692c61aa2299346064             1164 main/binary-amd64/Packages.bz2
 4881108a0da15f24ca2612cf079f345c             1084 main/binary-amd64/Packages.gz
 5c903ce25ce9411b2c2fdb970e683b5b              677 main/binary-i386/Packages
...

The equivalent part of Release is as follows:

...
 a28570dbcd7eb36c2f08a3bc8aee7c1c             2030 main/binary-amd64/Packages
 33358b1ec1e381b7f83fff383a57eb3c             1177 main/binary-amd64/Packages.bz2
 dccf6ed1786f560ead5750b0ff0be2ee             1087 main/binary-amd64/Packages.gz
 e9e086c484c19d6543978720e41f9780              677 main/binary-i386/Packages
...

As you might saw already for files Packages.bz and Packages.gz neither hash nor size match, but it is MUST! Such differences (even one is enough) make the repository non trusted and apt responses with following:

E: Неуспех при изтеглянето на http://linux.dropbox.com/ubuntu/dists/noble/main/binary-amd64/Packages.bz2  File has unexpected size (1177 != 1164). Mirror sync in progress? [IP: 18.165.72.41 80]
   Hashes of expected file:
    - Filesize:1164 [weak]
    - SHA512:a50404036f1307dff23fca233e708773fd5be5413450c1dd61a5b5030b133f714edc1f2494c67665458ef07a13c45352dd485847a93014cf0c19fbb10a92a423
    - SHA256:eee63bb11431bf7a4345465c38a3912b914437468858765a326f91258bee6d1a
    - SHA1:4d5c4648c1e90426338f36c0f4604178caa92e59 [weak]
    - MD5Sum:62674c968547a6692c61aa2299346064 [weak]
   Release file created at: Thu, 08 Jan 2026 18:17:55 +0000

Whatever change you have done at 8 January, only Release has updated, but InRelease hasn't!

Even more - finally it's time to send in retirement weak hashing/signing algorithms and replace them with some more strong - something that as it seems apt complains about too.

This is not something that directly breaks the application, but keeping this will prevent further package update.
I hope after your forwarding this to responsible team they'll keep it into account from now on.

Neal

Hi @Здравко,

Thanks for reporting this issue too!

I've since passed this on to our team and they have confirmed this morning that they have now fixed the issue.

Thanks again and please let me know if you need anything else!

Здравко

Hi @Neal,

At the beginning, I want to thank you for your help till now - the last repository issue.

Now I want to engage you in another one quite similar issue. It's about Year 2038 problem that DEB package system resolve with adding new naming schema. This change reflects in all recent releases of Ubuntu, Debian, and all other DEB based Linux distributions. Your current Dropbox application dependencies follow only the old naming schema; something that make new installs/updates impossible without workarounds!
Current dependency config line is:

Depends: procps, python3-gi (>= 3.12), python3 (>= 3.4.0), \${python3:Depends}, \${misc:Depends}, libatk1.0-0 (>= 2.10), libc6 (>= 2.19), libcairo2 (>= 1.13), libglib2.0-0 (>= 2.40), libgtk-4-1 (>= 4.8.0), libpango1.0-0 (>= 1.36.3) | libpango-1.0-0 (>= 1.36.3), lsb-release, gir1.2-gdkpixbuf-2.0 (>= 2.30.7), gir1.2-glib-2.0 (>= 1.40.0), gir1.2-gtk-4.0 (>= 4.8.0), gir1.2-pango-1.0 (>= 1.36.3)

Easy could be seen that some of the packages, participating here, are not available anymore with used above names (take a look here for instance). For example, package 'libglib2.0-0' is no more available and replaced by 'libglib2.0-0t64'. This makes Dropbox application disappear from compatible packages in all DEB related package managers!!!
It's an easy fix - just update/add correct package names. For example, some possible new form of the above line is:

Depends: procps, python3-gi (>= 3.12), python3 (>= 3.4.0), \${python3:Depends}, \${misc:Depends}, libatk1.0-0 (>= 2.10) | libatk1.0-0t64 (>= 2.52), libc6 (>= 2.19), libcairo2 (>= 1.13), libglib2.0-0 (>= 2.40) | libglib2.0-0t64 (>= 2.80), libgtk-4-1 (>= 4.8.0), libpango1.0-0 (>= 1.36.3) | libpango-1.0-0 (>= 1.36.3), lsb-release, gir1.2-gdkpixbuf-2.0 (>= 2.30.7), gir1.2-glib-2.0 (>= 1.40.0), gir1.2-gtk-4.0 (>= 4.8.0), gir1.2-pango-1.0 (>= 1.36.3)

I believe, updating of above line won't be difficult for the engineering team you have passed the previous discrepancy to. 😉 How long will take above line update?

If possible, please, check whether the main issue reported in ticket #25978720 is properly directed to correct engineering team. 🙏
There I described the posted here too, but part of the response is "there's more complexity behind the scenes that I can't see". 🤷 Is there something that Isaac cannot see? 😯 Is the link, I posted above (this one), is invisible to you too? Once you take a look on the ticked, I believe, you will understand my doubts.

Thanks in advance.

Neal

Hi @Здравко!

No worries at all, I'm happy to help and thank you for always giving such detailed feedback!

Let me check follow up on the ticket you shared and with the team and I'll see what I can find out.

I'll check back in with you if I have an update or if I have any follow up questions!