[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye



On 2021-02-13 03:02, Andrei POPESCU wrote:
On Vi, 12 feb 21, 17:00:41, Gary Dale wrote:
Which is why I think it would be useful to have way to rollback a package
when you can't fix it quickly. That way you aren't asking all the users to
do it themselves and track the bug status individually. When the maintainers
think they have a fix, it can go through the normal process...
Debian doesn't support downgrading of packages.

When dpkg installs another version of a package (typically newer) it
basically overwrites the existing version and runs the corresponding
package scripts from the to be installed version.

A newer package may introduce changes that the older package (scripts)
can't deal with. In practice it does work in many cases, except for
those where it doesn't. Fixing them would require a time machine ;)

A roll-back, especially if automatic, could introduce more issues than
it fixes.

Someone(tm) has to determine on a case by case basis whether rolling
back makes sense and the system administrator is in the best position to
do so.

In theory the package Maintainer could provide a general "hint" that
system administrators could chose to ignore (at their own risk).

Currently the infrastructure for this doesn't exist[1] and, besides, I'd
rather have Maintainers focus on fixing the newer package instead.


     Volunteer time is precious!


[1] it would need support in the Debian archive software and APT at a
minimum.

Besides, there is already an arguably safer (though hackish) way to
achieve that by uploading a package with version+really.the.old.version
instead.

In this case the Maintainer can also take care to adjust the package
scripts accordingly.

Random example found on my system:

$ rmadison fonts-font-awesome
fonts-font-awesome | 4.2.0~dfsg-1                      | oldoldstable     | source, all
fonts-font-awesome | 4.7.0~dfsg-1                      | oldstable        | source, all
fonts-font-awesome | 5.0.10+really4.7.0~dfsg-1         | stable           | source, all
fonts-font-awesome | 5.0.10+really4.7.0~dfsg-4~bpo10+1 | buster-backports | source, all
fonts-font-awesome | 5.0.10+really4.7.0~dfsg-4         | testing          | source, all
fonts-font-awesome | 5.0.10+really4.7.0~dfsg-4         | unstable         | source, all


Kind regards,
Andrei

I hear you, but the issue is that if I revert to a previous version, then I have to hold it to stop the buggy version from clobbering it every day. And I have to monitor the Testing version for changes to see when a fix is potentially available so I can remove the hold.

Not just me but every user who is experiencing the bug also has to do this.

There is a kludge for this if the buggy version didn't contain critical security fixes - re-release the previous version with a slightly higher version number than the buggy one (e.g. 3.7.0-5a). When the bug is (finally) fixed, give the fixed version a slightly higher number still (e.g. 3.7.0.5b).

Again this would only be done where it appears that fixing the bug may take time (it's been over a month now). If I were to do the alternative - pull packages from Sid - I have no real indication if they fix it or introduce even worse problems.

I can only assume that the reason a fix hasn't made it down through Sid yet is that it's not simple. My suggestion isn't to make more work for maintainers but rather to take the time pressure off them without leaving us testers to jump through hoops.



Reply to: