Re: sources.list urls for Etch
I have Etch and got my systems (laptop and desktop) running nicely.
I an still realitively new to Debian/Linux and love it.
I understand Etch is frozen and will soon be the stable version.
I want to make sure I have the correct urls in my sources.list file.
This is what I have now:
deb http://mirrors.kernel.org/debian/ testing main
deb-src http://mirrors.kernel.org/debian/ testing main
deb http://security.debian.org/ testing/updates main
I looked every where and cannot find anything conclusive.
This is what I have found so far:
deb http://ftp.debian.org/debian/ etch main contrib non-free
deb-src http://ftp.debian.org/debian/ etch main contrib non-free
I am in the United States.
Will these work?
What about the kernel?
How about security udates?
I use aptitude to maintain my systems and don't want to break anything
when I update.
1. Yes, that will work
2. Kernel images are usually only upgraded when installed manually (i.e.
apt-get install linux-kernel-2.6-latest), wether that also applies to a
dist-upgrade as will be the case when etch becomes stable I don't know.
But the entry in your sources.list is okay and the kernels in etch are
too, so you will be fine wether the kernel is automatically updated or
not, if you specifically want a newer kernel the just fire up your
favorite package managment tool and install a matching kernel for your
system or compile one to fit your needs.
3. To bring some light into the whole sources.list or debian repository
thing: On every official debian mirror the directories named testing,
stable, unstable etc. are only symbolic links to their respective
directories (i.e. testing points to etch, stable to sarge, unstable to
So the easiest thing for you to do is just to change every occurence of
"testing" in your sources.list to "etch" and your all set.
Note however that although with the release of sarge the maintainers,
debian crew or whatever you like to call them said that they were going
to speed up the release cycle, but unfortunately that wasn't the case
since it took us 2 years from woody to sarge and it will also be around
2 years from sarge to etch. What I mean to say by this is that if you
want to keep an up-to-date workstation which doesn't have to have 100%
uptime, you could just stick with testing since etch will probably as it
has been the case with the stable-flavor of debian be out-of-date by the
time of release already compared to cutting-edge distros.
P.S.: I love Debian and did not mean to offend anyone involved in
actually making it. My intention was merely to inform debian-neebies of
the fact that what in debian is called 'testing' is indeed less 'faulty'
than other distributions stable-tree.