Debian Plans for Freeze, Potato Release

marshall writes "I was reading the Debian Weekly News and was happy to see that Jan 2 will be the no new packages freeze for potato and Jan 15-16 will be the final freeze date with any new packages going into a new dist called woody. Then after some test cycles it looks like they are planning for a release at the end of Feb. The e-mail is here "

Comments

Relese dates and KDE 2.0 question.

[Forge]

Now if only Deb would take a page out of Linus' book and start having more frequent final releases. You see outside of the Hacker community ( I.e. Debian developers and the authors of the many packages included with debian ) You don't use something unless it's a final "stable" release or is included with a distribution that is "final and stable".

So yes, by all means hack the code until it shines. Make sure it works well but pleas do it quickly. As long as all that's out there is a stable release that's many months old and a self professed incomplete "developer release" you are essentially demanding that everyone interested in Linux try out something else.

Finally there is the question of KDE and Debian. Sure Corel Linux == Debian + KDE + Corel stuff; but dose the real Debian consider KDE 2.0 free enough for distribution ?

For the uninitiated KDE 1.x is not part of the official Debian because it relies on an unfree QT. QT 2.x ( on which KDE 2.0 depends ) is free so what's the word ? Are you just waiting for technical stability and completeness before this is included ?

PS : KRASH didn't crash on me so a stable KDE 2.0 isn't such a distant thing.

Re:Debian vs. Redhat

[smash]

I used Redhat from versions 4.1 - 5.2, and had a period of time during which i used both quite a bit (Redhat 4.2 and Debian 1.3 I believe). I have switched to Debian exclusively since Hamm (v2.0).

For me, the benefits which made me switch were:

1. The package management system.

.deb packages are much more versatile than rpms. You don't just have dependancies, you can have packages which "suggest" other packages. This tends to lead to packages which REALLY only depend on what they need for core functionality, as opposed to blah.rpm being compiled with every option enabled and requiring 35 different rpms to go with it.

Also, the new apt package management tools just rock. You no longer have to search for packages to satisfy dependancies, or even select what to download and install. Simply do:

apt-get install blah

and apt will work out what packages are required, give you a list, give you the amount of disk space required, both for downloading and after installation, and then ask for confirmation. Once you hit yes, you can happily leave it to download whatever and then come back when it is finished to configure.

2. File system structure

This is hard to put a finger on, and switching from Redhat will take some getting used to, but in my mind, Debian just has a much 'cleaner' file system layout. If you are after docs for package X they will be in /usr/doc/x pretty much without fail. ALL config files are in /etc/blah. The init scripts are easier to understand by your average human.

3. Central location for pretty much all packages.

With the exception of KDE, every single package on my system was downloaded from one of 2 sites. Either ftp.debian.org, or ftp.au.debian.org (the aussie mirror ;)


Also, a point to note is that to upgrade Redhat cleanly, I have had to reinstall for every new release.

I have installed debian ONCE on my machine in the last 18 months or so, and it is current, as of last night :)

Also interesting to note that Corel is based on Debian, which should prove interesting in the coming 12 months or so ;)


smash

Alien: your RPM friend

[lordsutch]

May I suggest alien; from the description:

Alien allows you to convert Red Hat, Stampede and Slackware Packages into Debian packages, which can be installed with dpkg.

It can also convert into Slackware, Red Hat, and Stampede packages.

alien will try to include as many of the dependencies it can grok from the RPM, so it will protect you a little better than using "raw" rpm. The maintainer, Joey Hess, did a great job here... it's not often needed, but when it is, it can be a lifesaver.