The do-release-upgrade script is not an option for us (and hence a number of our clients) running high availability clusters - since pacemaker-openais has been removed in favour of pacemaker/cluster-glue, the do-release-upgrade kills the node in the cluster by removing pacemaker-openais, making subsequent upgrades that rely on shared storage brought online via the crm fail painfully. Perhaps this is a bug against pacemaker, however it illustrates a point.
The path to achieving a successful upgrade for us and our clients would be:
- shift apt sources to lucid
- install pacemaker (fail due to this bug, and needs explicit upgrade of libxslt1.1)
- dist-upgrade
Also, the disabling by do-release-upgrade of custom repositories that we use to override official packages creates all sorts of headaches putting the pieces back together post-upgrade. The 'dist-upgrade' was created for a reason, and whilst I don't necessarily agree with the manor in which sam.watkins proposes it, I do agree with the sentiment that correct dependency chains are critical to a quality distribution, a core-value if you will.
So, we hack around this force-installing dependencies, etc...
The do-release-upgrade script is not an option for us (and hence a number of our clients) running high availability clusters - since pacemaker-openais has been removed in favour of pacemaker/ cluster- glue, the do-release-upgrade kills the node in the cluster by removing pacemaker-openais, making subsequent upgrades that rely on shared storage brought online via the crm fail painfully. Perhaps this is a bug against pacemaker, however it illustrates a point.
The path to achieving a successful upgrade for us and our clients would be:
- shift apt sources to lucid
- install pacemaker (fail due to this bug, and needs explicit upgrade of libxslt1.1)
- dist-upgrade
Also, the disabling by do-release-upgrade of custom repositories that we use to override official packages creates all sorts of headaches putting the pieces back together post-upgrade. The 'dist-upgrade' was created for a reason, and whilst I don't necessarily agree with the manor in which sam.watkins proposes it, I do agree with the sentiment that correct dependency chains are critical to a quality distribution, a core-value if you will.
So, we hack around this force-installing dependencies, etc...