After slipping a week from its alternate target date, Fedora 33 is in beta as of 9/29. For the past two weeks, it has been more than feasible to create packages for Fedora 33, as the environment is well-defined and only targeted bug-fix changes remain to be made before the final release. (Currently still scheduled for one week from today, 10/20, but possibly subject to slippage due to the delayed beta release.) Most packagers both within and outside the project have spent the past two months busily readying their package collections for testing during the F33 beta cycle, so that by release day everything will hopefully be fully tested and deployed.
...So, would anyone like to start an over/under on how many weeks after the Fedora 33 release it will be, before Dropbox finally make their F33 DNF repository available? I think F32 may have been a new record, since it only finally appeared two days ago, long AFTER the next release was already in beta!
(Or, you know, they could confound everyone's expectations by doing what every other software packager does, and working to prepare builds BEFORE the release — exactly as I described above — so that they're already available the day the new release comes out. Ball's in your court, Dropbox. You've missed Every. Single. Fedora. Release. since Fedora 18. Trust me, I've been counting. Consistency isn't always admirable.)
HI there @FeRDNYC; thanks for using Dropbox!
While I appreciate you taking the time to provide us with your feedback on this, I'm afraid we don't have a concrete timeline on when future repos will be released.
As you know, we do support a variety of operating systems, but we are unable to support beta (or experimental) versions until they are officially classified as stable.
On a side note, these packages install an open-source helper application and, as you noticed, the version of this application does not change as frequently as the main Dropbox application.
The packages there though will always install the latest version of Dropbox for Linux.
I hope this information helps to some extent and please let us know if you have anything to add or ask.
We appreciate your comments about the Fedora 33 repository.
We take all feedback seriously and our dev team are aware of this matter.
Once again, after a new Fedora release, there are errors when we attemp to update Dropbox indicating the following:
Errors during downloading metadata for repository 'dropbox': - Status code: 404 for https://linux.dropbox.com/fedora/33/repodata/repomd.xml (IP: 18.104.22.168) Error: Failed to download metadata for repo 'dropbox': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried
This occurs because the location
has not been created for Fedora version 33. This occurred with the release of Fedora 32 (July '20) as well and was eventually corrected a month later as a result of support ticket #10988692
Details of that episode can be found here:
Hey DropBox, any chance you can update your release process so this doesn't happen as often? If there is no change then a simple link to the old version is all that is typically needed.
I think you miss the point that FeRDNYC is making. The facilities are there for your development team to prepare for a release on the next Fedora version before that version drops. I can see a short time between the OS version release and your Dropbox release supporting it due to testing and QA but it takes much more than that on your side for every release. It appears that no work is done until the OS announces it's release.
Even when the new OS versions drop, the current Dropbox version has been working (so far). But the update process on Fedora will consistently balk because you are not providing a link that it recognizes as a valid one. This leaves most of your Fedora based users continually looking at error messages in their update logs that are really no-ops.
All we really need is a link to the latest Dropbox version that works in the most current released Fedora version. Run your QA suite on the latest Fedora and if it passes just provide us a link for it pointing back to the current Dropbox version.
I can't verify it but I suspect other Linux distros may be in similar positions.
Thank for listening/reading.
I remember encountering this before, a couple of years ago, but I don't remember which distro. (CentOS???) I fixed it by hardwiring it on my end that time too. On both occasions, I encountered this issue immediately after installing Dropbox - obviously they thought they had something that worked even though the "correct" repo didn't exist. I don't understand why it's so hard for the Dropbox folks to just link it on their end to whatever version they're giving me when I do the initial install.
The following /etc/yum.repos.d/dropbox.repo file will use the current version repo if available, and fall back to Fedora 32 otherwise:
[dropbox] name=Dropbox Repository baseurl=https://linux.dropbox.com/fedora/$releasever/ https://linux.dropbox.com/fedora/32/ failovermethod=priority gpgkey=https://linux.dropbox.com/fedora/rpm-public-key.asc
The way we work is changing. Share and discover new ways to work smarter with Dropbox in our community.Sound good? Let's get started.
For more info on available support options, see this article.
If you found the answer to your question, please 'like' the post to say thanks to the user!