Downgrade is the new upgrade
Downgrade is the new upgrade
Posted Dec 22, 2011 5:31 UTC (Thu) by dlang (guest, #313)In reply to: Downgrade is the new upgrade by jrw
Parent article: Ubuntu disabling the Sun Java JDK browser plugin
what tool do you use to do your upgrades? every one of the GUI tools I have seen allows you to look at each package being upgraded and see the description of the package.
> I also noted that some kind of checkpoint system would be very helpful in dealing with updates. I would love to see an auto-checkpoint updating system that allows me to roll back an update. I have had occasion to wish for it several times in the past.
this is something that many people would like to see, but actually implementing it is very hard, and can take a non-trivial amount of storage to do so (and how do you decide how long to keep this?)
If you really want this, run your system on top of LVM and take a snapshot just before you upgrade so that you can revert back to it.
Posted Dec 22, 2011 6:16 UTC (Thu)
by jrw (subscriber, #69959)
[Link] (5 responses)
> what tool do you use to do your upgrades? every one of the GUI tools I have seen allows you to look at each package being upgraded and see the description of the package.
I misread your original comment here. I use Update Manager and I have never found its detailed information useful. In this case I didn't read the detailed information. I browsed through the list of things to be updated, didn't find anything especially interesting in the list of packages, and authorized the update. I didn't find out until I rebooted one or two days later and tried to use Netilla that java had been removed.
What I'm asking for is something in-your-face when there's an expected loss of functionality. When there's a security fix, it should stand out as a danger if you don't accept the update. When there's an expected downgrade, it should stand out as a danger if you do accept the update.
>> I also noted that some kind of checkpoint system would be very helpful in dealing with updates. I would love to see an auto-checkpoint updating system that allows me to roll back an update. I have had occasion to wish for it several times in the past.
> this is something that many people would like to see, but actually implementing it is very hard, and can take a non-trivial amount of storage to do so (and how do you decide how long to keep this?)
I would think that the bulk of what I'm looking for could be achieved by just keeping the previous packages around so they can be reapplied. If a rollback is required, remove the packages that have been added and reapply the packages that have been removed.
> If you really want this, run your system on top of LVM and take a snapshot just before you upgrade so that you can revert back to it.
Perhaps LVM could be helpful here, if the LVM snapshot could be applied to just the OS partitions. Do you know of a How To for using LVM snapshots to rollback OS updates?
Posted Dec 22, 2011 6:57 UTC (Thu)
by dlang (guest, #313)
[Link] (1 responses)
so when you upgrade to GNOME 3 it should warn you that you are about to loose a lot of functionality?
somehow I don't see this taking place.
remember that every upgrade can contain regressions for somebody under some conditions.
Ubuntu does mark some upgrades as being security related. I generally use the command line not the GUI tools, so I can't point you directly at the place to look, but what I remember seeing in passing is that when presented with the list of packages to upgrade, there is a category of security patches.
> I would think that the bulk of what I'm looking for could be achieved by just keeping the previous packages around so they can be reapplied. If a rollback is required, remove the packages that have been added and reapply the packages that have been removed.
you are overestimating the smarts of the packaging tools.
a package contains several pieces, the bulk of the package is the files to install on the system.
However the complicated part of the package are the parts that prepare the system, or change the system as part of the upgrade (frequently modifying config files). These are scripts that can do anything to the system, but these scripts only know about the version of the software that's you are installing (or uninstalling for scripts that make changes when you uninstall a package), they don't know what version used to be on the system, and they cannot possibly know about what changes a newer version may have made to config files to convert them back.
This makes a package based upgrade backout _extremely_ hard to do, and given that a large percentage of upgrade problems have to do with failures of these scripts (not converting config files perfectly), relying on them to be perfect in doing a downgrade is silly.
you may be thinking "well, just make backup copies of the config files then", but this isn't limited to config files, this process can modify _anything_ on your system, databases, files, directories, ANYTHING. This is why installing packages from an unknown source can be so dangerous.
Posted Dec 22, 2011 8:03 UTC (Thu)
by jrw (subscriber, #69959)
[Link]
Also, I'm certainly aware that regressions can happen at any time and there's always some risk when updating. In fact, not so long ago, one of those regressions occurred for me during an upgrade and broke the same application (Netilla). I was not happy about that either, but I believe that it was an accidental regression. It was fixed a few days later.
In this case, the regression was well known (by the package maintainers) in advance, and in fact, the entire reason for the update was to effect a regression! That's what makes this case different and worth discussing.
As to the possibility of restoring previous versions of packages, I believe it would be a welcome step forward if the user could just retrieve and reinstall the exact previous version of the packages he just updated, in the case of a detected regression. That still seems doable in the vast majority of cases. I do understand that in some exceptional cases the changes wrought by a newer package could be so far reaching as to make recovery by reinstallation of the older package unworkable.
I'll have to look into using LVM as a checkpoint mechanism to be able to revert failed updates. But if it can't be scripted up pretty easily, it won't be worth it.
Posted Dec 22, 2011 11:35 UTC (Thu)
by nix (subscriber, #2304)
[Link] (2 responses)
Posted Dec 22, 2011 13:33 UTC (Thu)
by jrw (subscriber, #69959)
[Link]
Posted Dec 22, 2011 21:29 UTC (Thu)
by JanC_ (guest, #34940)
[Link]
>> If I knew where to find this information, I would read it.
Downgrade is the new upgrade
Downgrade is the new upgrade
Downgrade is the new upgrade
Downgrade is the new upgrade
What I'm asking for is something in-your-face when there's an expected loss of functionality.
The irony is that text-mode updates have had this for something like ten years, thanks to apt-listchanges' NEWS-file reporting. Graphical package managers don't seem to have caught up.
I'll have to look into scripting a replacement using apt/dpkg. Thanks for the heads up!
Downgrade is the new upgrade
Downgrade is the new upgrade