DebianThis forum is for the discussion of Debian Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Personally, I stick with "testing" always. Plus I regularly install specific programs in which I'm interested from Sid. Unless you are running a critical server, or production workstation, Testing is a better environment. That way you keep a current system. Debian Testing is much more stable than the new every-six-months releases of other distros.
All programs in Testing have already been active in Sid for a while without any critical bugs filed. So if you do encounter a bug in a Testing program, it's not likely to cause any serious harm.
In the past I have tried on several occassions to get my sources file to use Etch instade of testing. It has always failed when I change it. I am not sure why. It does accour to me that I might be making a upper case lower case mistake. I haven't persued that though. In the event that this is my mistake should it be "Etch" or "etch"?
Baring that I am puzzled. I only try changing that one word. If I change it from testing to stable it works. But not if I change it to etch. The syntax is set by the program (can't recall the name) that pings the servers, does a trace on them and then picks the fastest one and wrights a new sources file.
deb ftp://debian.mirrors.pair.com/ etch main non-free contrib
and I get a few packages that can be upgraded but I don't get the thousands that are avalible with testing. I have tried other servers too. Do they only put a partial list in Etch and the whole list in testing?
Also I guess I don't really understand how apt references the files on the server. When I point my browser to the server I can see the list of files but I don't understand how it can get to etch or testing for that matter because there is no / inbetween .com and etch. On top of that there is not even a file with that name. Where is a good basic explanation, something fast and easy? I have to many things to do and not enough time to do them all and this is low on the priority list.
Oh well testing works. Just a little concerned with Etch going stable soon. My wife hates it when something brakes on the comp and I would like to give testing about 6 months before I go back to it. Any idea how much longer before Etch goes stable?
I don't understand how it can get to etch or testing for that matter because there is no / inbetween .com and etch.
The lines in your sources list include pieces of data that are not part of the url. If you really want to understand it, you'll have to study Apt. That should keep you busy for a few years. Suffice to say that "etch" or "testing" tells apt which variety of Debian you are using, therefore, which version of the program to offer if it has an update.
You don't need to understand the inner workings of Apt, but you do need to know how to use it. You should also try to understand the difference between apt-get and aptitude.
Doing a dist-upgrade does not offer you the tens of thousands of packages available on Debian. Only the ones you already have that have updates available, and a few others that have been identified for inclusion in the core distribution. Other programs, you have to find out about yourself, and purposely install them.
My guess is that Etch will go "Stable" in the next couple months, but nobody knows for sure. The Debian rule is "Release when it's ready, and not until." Right now it is in a "frozen" state which means that nothing new will be added ... only bug fixes. There are still about 100 bugs known in those 20,000+ packages, but the odds of you encountering one are exceedingly slim.
Most of the time I use kpackage or synaptic for my package management, so I can see the whole list (20,000?), everything that is avalible when I point my sources to testing. But when I point it to etch I get very few. This is what puzzles me. I can see the difference in how fast synaptic or kpackage initiliazes when it is pointed to etch verses testing. Etch is very fast and testing takes a minute or so. Some how etch is not grabbing the complete list of what is avalible. Any way on to more important things.