[TriLUG] Debian operaton.

Neil Roeth neil at occamsrazor.net
Sat May 24 22:30:15 EDT 2003


On May 24, Bill Gooding (bgood210 at yahoo.com) wrote:
 > So I am working with my standard installation of Debian woody (3.0r1).  The
 > first thing I wanted to do was get some testing versions of certain
 > software installed.  I modified my sources.list file to be the
 > following to add the appropriate testing elements.  Then I would type
 > "apt-get -t testing install gv".  It didn't work even though I had the
 > appropriate elements in my sources.list file.  The sources.list file I

You can execute "apt-get install gv/testing" to install the version from
testing, given the sources.list that you posted.

 > update => Make the current /var package archive list consistent with
 > sites listed in the current /etc/apt/sources.list. So apt-get update
 > is the only command that looks at your sources.list.  Everytime you
 > change sources.list you must run this command.

You need to run it more often than that.  It's implied by what you said that
your system will never know that newer packages exist unless you execute
"apt-get update".  You will almost never need to change sources.list once it
is set up, but in unstable, for example, the most recent packages available
change daily.

 > upgrade => Updates the current release on your computer to the most
 > recent version of the current release on your computer

This is how you upgrade older versions of individual packages to newer
versions.  Think XEmacs 21.2 to 21.4, rather than RH8.0 to RH9.0

 > dist-upgrade => Upgrades the current distribution to the next one
 > (i.e. 3.0 to 4.0/stable to testing)

This is the equivalent of an upgrade from RH8.0 to RH9.0.

 > So my mistake was thinking that apt-get read the sources.list file
 > every time you execute an apt-get command.  It really reads the
 > package archive on /var.  That package archive doesn't contain entries
 > for the testing versions until you run apt-get update. It might help
 > the apt-get HOWTO if in the introduction they gave a clearer model of
 > how apt-get works.
 > 
 > Now Debian experts like Ben may say "RTFM, you idiot" (and I do think
 > he is an expert, many people who are actually experts at something
 > will not say they are, alot of times people who say are experts really
 > are just talk).  He may not say that, I don't know.  I have admitted
 > that this is mostly my fault, and that's true.  And it only took me an
 > hour or so to figure out the problem.  After realizing what I have, I
 > read the APT HOWTO more carefully and this is documented (it isn't
 > that strongly emphasized though).  I think any blame on me is somewhat
 > mitigated by what I think is a questionable use of terminology by
 > Debian apt-get.  This problem may actually be historical (i.e. someone
 > made this decision a long time ago and they are stuck with it).  I
 > also think that the software design is correct, the way they design it
 > if you run an upgrade and don't have any packages to update, it
 > doesn't hit the network.  My problem is merely with the terminology.
 > If someone using Redhat 8.0 told you he "upgraded" his system,
 > wouldn't you think he meant that he is now running Redhat 9.0 ?  I
 > would think that.  But if he told me he "updated" his system, I would
 > think he got the most recent version of Redhat 8.0.  This is not how
 > Debian apt-get is, so be careful.

As the saying goes, this is well known to those who know it well :-) I
personally don't find the terminology confusing, but I admit to an ever so
slight bias.

 > There is second small problem with the version of apt-get that is
 > given in woody.  You may wonder in my sources.list file I gave why I
 > didn't just add the unstable entries to it.  That way, I could get
 > whatever I wanted via "apt-get -t" and do upgrades to get the current
 > stable base.  When I added the entries for unstable, it gave an error.
 > The error is recognized and solved already by the Debian people.  But
 > the corrected version of apt is currently in unstable.  If you get the
 > unstable version of apt, you can use the following sources.list (which
 > is my current one):
 > 
 > 
 > deb http://ftp.us.debian.org/debian/ stable main non-free contrib
 > deb-src http://ftp.us.debian.org/debian/ stable main non-free contrib
 > deb http://non-us.debian.org/debian-non-US stable/non-US main contrib
 > non-free deb-src http://non-us.debian.org/debian-non-US stable/non-US
 > main contrib non-free
 > 
 > deb http://security.debian.org/ stable/updates main contrib non-free
 > 
 > deb http://ftp.us.debian.org/debian/ testing main non-free contrib
 > deb-src http://ftp.us.debian.org/debian/ testing main non-free contrib
 > deb http://non-us.debian.org/debian-non-US testing/non-US main contrib
 > non-free deb-src http://non-us.debian.org/debian-non-US testing/non-US
 > main contrib non-free
 > 
 > deb http://ftp.us.debian.org/debian/ unstable main non-free contrib
 > deb-src http://ftp.us.debian.org/debian/ unstable main non-free
 > contrib deb http://non-us.debian.org/debian-non-US unstable/non-US
 > main contrib non-free deb-src http://non-us.debian.org/debian-non-US
 > unstable/non-US main contrib non-free
 > 
 > Remember to run "apt-get update" every time you change your
 > sources.list file. Then it should work.

If you have all three versions in your sources.list, you need to be careful.
Mixing stable, testing and unstable packages on your system is like installing
RH7.1, RH8.0 and RH9.0 to run simultaneously in the same filesystem.  You'll
eventually run into a situation where a simple "apt-get install foo" will try
to install dozens of other packages, due to the extensive dependency
information that makes Debian so great.  Even though Debian is generally rock
solid, it is Linux, so it will let you shoot yourself in the foot if you work
hard enough to do so.  You are sometime better off downloading the source from
testing or unstable and compiling it in the stable environment.  With your
setup, that would require the command "apt-get --compile source foo", perhaps
with some qualifier to tell it which version of foo to get.

A very important option for apt-get is -s, or --simulate.  This will work with
the install, upgrade or dist-upgrade commands, and will show you what the
command would do without actually doing it.  So, you would see that package
foo is about to drag in dozens of other packages before it actually did that.

I set up my machines (mostly running unstable, which changes frequently) to do
"apt-get update && apt-get -dy upgrade" nightly.  This updates the list of
available packages, and downloads them to my local disk without actually
installing them.  Then I periodically to "apt-get -s upgrade" to see what
would be installed, then usually do "apt-get upgrade" unless I've read on the
mailing lists that some important package is in a bad state.  I would not
recommend that anyone do "apt-get upgrade" automatically.

 > Another minor note - at one point I recommended that people use the
 > graphical installer when getting new packages for Debian.  I don't
 > know if this such a good idea (at least for woody distribution).  When
 > Debian installs a package for you, it usually asks some questions
 > about how the package should be configured.  They have a "Dialog"
 > routine that is responsible for asking those questions.  If you use
 > the graphical installer (the one for KDE at least), it is unable to
 > run the Dialog routines, and therefore unable to ask you configuration
 > questions.  It still installs the package, but you want to be careful
 > in case one of the questions is answered in a way you don't like.  You
 > can always just uninstall and reinstall the package if there are
 > problems or there may be a command (dpkg-reconfigure ??).  My
 > recommendation is to use the graphical installer to see the packages
 > available, but use apt-get at the command line for actual install so
 > the Dialog questions get asked.
 > 
 > Also the Debian practice of asking installation questions for some of
 > the packages it installs is a difference with respect to Redhat.
 > Redhat asks far fewer questions (if any) when you install some
 > package.  Redhat makes default choices for you.  I think I like the
 > Debian approach better on this issue (although the main type of
 > questions I am getting now are just about my fonts, which I mostly
 > don't care about).  I think that for sysadmins it allows for easier
 > and more flexible configuration.  I am sure Debian won't ask all the
 > questions necessary for a complicated system, but it does help and it
 > sometimes tells file locations and other information.  Obviously, you
 > need to know alot about the configuration files in any package to do a
 > good install.  Debian won't do it all, but it helps.  If Debian had a
 > way to specify a default answer for the Dialog questions, it might be
 > nice for normal users who don't want to be bothered.  But it wouldn't
 > be sufficient to say default=yes, because some of the Dialog questions
 > actually are set to answer no (if you just hit return).  That way
 > Debian would have a standard installation (for normal users) and be
 > configurable (for experts who would answer the Dialog questions).
 > They may actually already have this feature and I just haven't
 > bothered to look.

I think you are talking about debconf, and yes, you can configure it to ask
questions at four different levels, so it can be completely interactive, using
defaults for all questions, or it can ask something at about just about every
step.

-- 
Neil Roeth



More information about the TriLUG mailing list