Re: Some bits of experience gained from handling upgrade-reports.
Bill
Just out of curiosity, when testing the upgrade procedure how do you
select the mix of packages installed prior to the upgrade?
Steve
Bill Allombert(allomber@math.u-bordeaux.fr)@2005-06-09 22:53:
> Hello Debian developers,
>
> [Please store this mail in a safe place and read it when you have
> recovered from the release party.]
>
> During the few weeks before sarge release, I have tried to reproduce the
> upgrade problems reported to upgrade-reports [1]. I reached the following
> conclusions:
>
> 1) Circular dependencies are cause of lot of breakage. Worse, the
> problem that plague the woody to sarge upgrade are not circular
> dependency in sarge but in woody. It means that if we want a nice etch
> to etch+1 transition, we need to try to get rid of them now.
> Usually it can be achieved by spliting packages to isolate the
> dependency.
>
> 2) apt and aptitude reliance on C++ make them quite painful to upgrade
> before doing the dist-upgrade due to C++ ABI changes. This issue is
> likely to be the same during the sarge to etch upgrade, so we should not
> rely on the user installing the latest apt or aptitude version before
> upgrading.
>
> 3) There are far too many packages that mess with conffiles causing
> useless dpkg conffiles handling. We should strive to do better in etch.
> Never move a conffile in a maintainer script without checking the md5sum
> against the stable version of the conffile. If it match, remove it
> instead instead of moving it. It is the same if you use ucf instead.
>
> 4) Upgrade-test need to be done continuously because there is not enough
> time during the freeze to fix all the problems. Another conclusion is
> that this need to be done automatically. This could be done roughly
> the same way as a buildd work, but would generate a 'upgrade
> certificate' instead of a package. Such test will also find the
> packages that cannot be installed due to maintainers scripts breakage.
>
> Unfortunately I do not have access to suitable hardware anymore to do
> such upgrade test, so help with this project would be more than
> welcome. Some kind of virtualisation technology like user-mode-linux
> might be required (that is what I was using).
>
> As a conclusion, I am not very happy with the state of woody to sarge
> upgrade. I expect around 30% of users will suffer serious breakage that
> could have been avoided. This statistic assume smart users. We should do
> better for etch.
>
> Acknowledgement:
> I would like to thanks Frans Pop and Steve Langasek for bearing with me
> while I was inflating the release notes changes and the RC bugs count and
> for generally be helpful at trying to solve upgrade issue.
>
> I would also like to thanks people that took the trouble to send
> upgrade-reports.
>
Reply to: