disabling version checks

[anarcat]

Hi!

Debian sponsor here (a sponsor is a Debian developer who uploads a package built by a non-developer)… I’m coordinating with the packager to get the Debian version updated to latest (0.9.8) but in the meantime, RPD is popping up this version check dialog on startup… In fact, it’s doing network requests to check for new versions on startup, which is not really necessary: end-users can’t actually act on those warnings because the program is installed through a Debian package.

I’m wondering if we should patch away the version check, or if there’s already a toggle we could use in the Debian package to disable those checks.

I’m looking at rapid.py's stage4 initialization, and I am thinking of introducing a simple boolean around this code:

if skip_version_check:
        logging.debug("Starting version check")
        self.newVersion = NewVersion(self)
        self.newVersionThread = QThread()
        self.newVersionThread.started.connect(self.newVersion.start)
        self.newVersion.checkMade.connect(self.newVersionCheckMade)
        self.newVersion.bytesDownloaded.connect(self.newVersionBytesDownloaded)
        self.newVersion.fileDownloaded.connect(self.newVersionDownloaded)
        self.reverifyDownloadedTar.connect(self.newVersion.reVerifyDownload)
        self.newVersion.downloadSize.connect(self.newVersionDownloadSize)
        self.newVersion.reverified.connect(self.installNewVersion)
        self.newVersion.moveToThread(self.newVersionThread)

        QTimer.singleShot(0, self.newVersionThread.start)

        self.newVersionCheckDialog = NewVersionCheckDialog(self)
        self.newVersionCheckDialog.finished.connect(self.newVersionCheckDialogFinished)

        # if values set, indicates the latest version of the program, and the main
        # download page on the Rapid Photo Downloader website
        self.latest_version = None  # type: version_details
        self.latest_version_download_page = None  # type: str

would that work? i would need to figure out how to properly initialize skip_version_check but that could be done through a minimal patch in the debian package, to avoid getting us out of sync…

what do you think?

thanks!

[damonlynch]

To be clear about what is being proposed:

There is a preference setting:
http://damonlynch.net/rapid/documentation/#versioncheck
By default it is on.

If version checking is enabled, and a new version is detected, the program will only prompt to auto-update if it has been installed using pip. If it is installed in any other manner, the user will merely be prompted to open the program website, where they can learn more about the new release.

FWIW the installer script on my website will automatically uninstall distro packaged versions of Rapid Photo Downloader packages, including those in Debian.

In future, a PPA, a snap and if it can be made to work an appimage would be nice.

However, while I consider these user friendly features, my guess is that you prefer that Debian users install only Debian packages, and not be confused by other installation methods or possibilities. I imagine that’s the explanation behind the complete removal of the version check for VLC when running the Debian / Ubuntu distro package, for instance. I can see how that makes sense in several scenarios.

The upshot of all of this is that the changes to make Rapid Photo Downloader to conform to this relatively locked-down approach is that it requires changes in the user interface too, not just the code block you have identified. I note that the VLC distro package GUI has also had the version check stripped out.

I think in such a case, a patch that manipulates program logic is a poor way to implement this proposal. It would be a pain in the ass to maintain, and prone to breakage. Instead a value should be set in the file constansts.py, which Debian and other distros can “patch” to set to disable the version check. I will need to write the code to disable the version check logic in the UI as well as in the program logic.

If you agree with this approach, I can write it today, and release it as version 0.9.9. However, in exchange I’d like to see version 0.9.9 be packaged in time for its inclusion in Ubuntu 18.04.

[anarcat]

@damonlynch

If version checking is enabled, and a new version is detected, the program will only prompt to auto-update if it has been installed using pip. If it is installed in any other manner, the user will merely be prompted to open the program website, where they can learn more about the new release.

Hmm… in 0.9.7 here, the “version check” box is off, and I still get prompted for the new update… Is that normal?

@damonlynch

However, while I consider these user friendly features, my guess is that you prefer that Debian users install only Debian packages, and not be confused by other installation methods or possibilities. I imagine that’s the explanation behind the complete removal of the version check for VLC when running the Debian / Ubuntu distro package, for instance. I can see how that makes sense in several scenarios.

Yes, that’s basically the idea: we don’t want Ubuntu/Debian users installing RPD through Debian package be prompted for an update when they expect to update the package through the packaging system. If they want to follow the upstream packages, they are still free to use the installer, but since they chose the package, I think we should assume they don’t want to be bothered with those checks.

@damonlynch

I think in such a case, a patch that manipulates program logic is a poor way to implement this proposal. It would be a pain in the ass to maintain, and prone to breakage.

I agree. this was only a quick suggestion.

@damonlynch

Instead a value should be set in the file constansts.py, which Debian and other distros can “patch” to set to disable the version check. I will need to write the code to disable the version check logic in the UI as well as in the program logic.

If you agree with this approach, I can write it today, and release it as version 0.9.9.

Adding something we can patch easily in constants.py makes sense to me. It’s pretty much what I was getting at in my proposal…

@damonlynch

However, in exchange I’d like to see version 0.9.9 be packaged in time for its inclusion in Ubuntu 18.04.

What’s the deadline for 18.04?

[damonlynch]

The import freeze for Ubuntu 18.04 passed 5 days ago.

However, with good reasoning, it’s sometimes possible to get a MOTU (Master of the universe) to make an exception.

[anarcat]

@damonlynch

The import freeze for Ubuntu 18.04 passed 5 days ago.

However, with good reasoning, it’s sometimes possible to get a MOTU (Master of the universe) to make an exception.

I can’t promise anything regarding that, unfortunately, as that is completely outside of my control.

[damonlynch]

It would be an enormous help if the Debian package was created promptly, without a delay such that getting it into Ubuntu 18.04 will be impossible. If the 0.9.9 Debian package will not be released for several weeks, then our discussion is moot, because it will be too late.

[anarcat]

@damonlynch

It would be an enormous help if the Debian package was created promptly, without a delay such that getting it into Ubuntu 18.04 will be impossible. If the 0.9.9 Debian package will not be released for several weeks, then our discussion is moot, because it will be too late.

this is out of my control. What i can do is a “NMU” (non-maintainer upload, because i’m just the sponsor), which would kick in 10 days after my upload.

[damonlynch]

Is the purpose of an NMU to work around maintainers who do not actively maintain their packages?

[anarcat]

@damonlynch

Is the purpose of an NMU to work around maintainers who do not actively maintain their packages?

NMU is defined in the developer’s reference as:

In some situations, it is useful that other developers can upload a new version as well, for example if they want to fix a bug in a package they don’t maintain, when the maintainer needs help to respond to issues. Such uploads are called Non-Maintainer Uploads (NMU).

The idea is to fix bugs even if the maintainer is away or busy. There’s a different process to deal with non-reactive maintainers.

[anarcat]

as i mentioned here:

Rapid Photo Downloader 0.9.9 is released

i uploaded this as a “NMU” (Non-maintainer uploader) to Debian, which will take 10 days to trickle down to unstable, and from there, another 10 days to trickle down in testing. I don’t know how much time it will take to trickle down into Ubuntu, and some work will be needed to make the cut for 18.04LTS, but that’s outside of my jurisdiction now. BTW, as part of the NMU process, we have the habit of sharing a diff between the two versions on the bugtracker. This was a problem for RPD the diff be…

this new feature should land in Debian shortly but I have no control over Ubuntu…

thank you so much for the quick response!