Re: Sarge-based Debian-Edu/Skolelinux 2.0 Released as Stable
Hi,
On Tue, 28 Mar 2006, Finn-Arne Johansen wrote:
> Well, you can read about it at
> http://wiki.debian.org/DebianEdu/HowTo/UpgradeFrom1.0
This is exactly what I was looking for, thanks Finn-Arne. Sorry I must
missed the Howto link on the wiki :(
> And then judge for yourself. I felt it was more important to stop people
> from installaing the woody-version ~5 years after most of it's software
> was released, than to make a clean upgrade path.
I guess so. As Jonas mentions, it might be no harm to mention the possible
upgrade issues on the download page.
> What is causing us trouble in short is:
> - 2 perl packages, that leaves perl in an un-upgradable state (dont
> remember the exact bug though)
> - inconsistance in the ldap db. To put it short:
> I think this happens if any of the groups admins, teachers, jradmins
> or studens is empty.
I might try and ensure there's someone in each of these.
> make sure you have the following line in your sources.list
> deb http://ftp.skolelinux.no/skolelinux sarge local
Will do. Is there any benefit to having the cd available (it's a 2MBit
aDSL)?
> Well, it's kind of documented, but you can make the documentation better.
I'll see what I can do. I must say the presentation of
http://wiki.debian.org/DebianEdu/
makes it quite hard to pick out a page as important as the Howtos.
> But one thing that we can learn, is that we need a lot of tester
> _before_ debian etch is released as stable. I think at least that the
> upgrade trouble of the perl files should have been taken care of before
> sarge was released. That is why we need to work on the reelase of etch
> now, to make sure all our "needed" packages are availible before etch is
> frozen. Then we'll have ~5 months to find all the bugs preventing a
> clean upgrade. Of course it would have been nice if we could find the
> bugs preventing a clean upgrade before etch is frozen, but I have my
> doubt that we will manage. In fact, if we had not managed to release 2.0
> now, we would have ben worse off.
I haven't wanted to test the upgrade on a live system but this is very
often what needs to be done. I guess I could use something like system
imager to clone the server, upgrade and see what happens. This could be
used both to test upgrades with release candidates on pseudo live systems
as well as test one's own upgrade prior to jumping in on the live one.
I guess a good doc on how to do this would be a good contribution too.
> As said - get all your stable production servers upgraded into sarge
> now, and then help us test the upgrade path to etch.
I'll do my best.
Thanks for the information,
Gavin
Reply to: