This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
Date: Wed, 28 Feb 2001 22:46:10 -0800
To: World Domination <svlug@svlug.org>
Subject: Re: [svlug] Debian order of things
From: Rick Moen <rick@linuxmafia.com>
Wow, you're sort of building up this system from the bare minimum.
begin Todd Lyons quotation:
> non-US Packages got a "404 Not Found"
Todd, edit the relevant line in /etc/apt/sources.list for the non-us
package source to read:
deb http://non-us.debian.org/debian-non-US stable non-US/main non-US/contrib non-US/non-free
That should, of course, be all on one line. I'm unclear on how yours
got messed up.
Whenever you type "apt-get update", the system queries each package
source listed in /etc/apt/sources.list, to get its latest list of
available packages (and the related "Release" file). Those two files
(the "Release" and "Packages" file) for each package source land in
/var/state/apt/lists . As its last step, the command then merges the
Packages files, and stores the result as /var/lib/dpkg/available.
You'll notice the actual package database file (the list of installed
packages) in the same directory, as /var/lib/dpkg/status. It's an ASCII
file: You can fix it with a text editor, if anything goes wonky with
one of the installed packages, e.g., by snipping out the package's
paragraph.
The other command you gave was "apt-get dist-upgrade". This causes the
system to fetch any .deb packages for any updated versions available at
your upstream package sources of the installed software, and any new
packages that might be required by them (in both cases, as determined by
comparing /var/lib/dpkg/available to /var/lib/dpkg/status).
If I read you correctly, you quite the Debian 2.1 installer completely,
at the point where you were put into dselect. If so, you then had a
really, really spartan Debian 2.1 system. Your two apt-get commands
have now upgraded that to a really, really spartan Debian 2.2 system.
There are a whole heck of a lot of nearly essential packages you
presently lack, in consequence -- like the "man" command, for instance.
You thus may want to start with the following:
apt-get install autoconf automake bin86 binutils bison cpp doc-base
dpkg-multicd file flex g++ gcc groff info less libc5 libc6-dev
lilo make man-db manpages psmisc sysutils xbase-clients xlib6 xlib6g
xlib6g-dev xserver-common xfree86-common xf86setup xbase-clients xlib6
xlib6g xprt xfs xfstt xfonts-scalable xfonts-base xfonts-75dpi
xfonts-100dpi
...all on one line.
If apt-get complains that any of those don't exist, hit up-arrow,
backspace out the package, then resubmit.
Then, spend a little time in tasksel picking out metapackages to flesh
out your system. (Don't forget to include the appropriate X server.
My old http://linuxmafia.com/debian/tips thing might be of some use
to you, although it's a horrible hodgepodge, and outdated.
===
Date: Thu, 01 Mar 2001 20:36:45 -0800
From: Todd Lyons <todd@mrball.net>
To: Ivan Passos <lists@cyclades.com>
Subject: Re: [svlug] Debian order of things
Rick, thanks for the apt-get line. I chose to start with the very base
minimal system just because I wanted to KNOW what was being installed on
the system. One interesting thing is that X started up first try at the
highest resolution I've ever been able to achieve in ANY OS (on my
Toshiba Tecra 720 CDT). I'd suspect one of the developers has one :)
Ivan Passos wrote:
> > That should, of course, be all on one line. I'm unclear on how yours
> > got messed up.
> In my original 2.1 Debian system, I had:
> deb http://non-us.debian.org/debian-non-US non-US main contrib non-free
> , which of course didn't work. Maybe this was the same problem he had.
Bingo.
Now for the next round of interesting stuff.
1) Edited the deb line.
2) apt-get install <snip>
3) segfault installing binutils. says to run dpkg --configure -a.
4) run dpkg --configure -a cuz nothing else works :)
5) rerun apt-get install <snip> which pickus up from binutils and
completes successfully
It all runs properly, but it sure does seem strange that the binutils
install segfaulted. binutils did install properly when the apt-get was
rerun in #5. Ever seen this before?
I see references to unstable. I am using (apparently) stable. Do I
need to modify the deb lines again or do I need to alter my apt-get
commands? I've not looked much on this, so I'll scan through the SVLUG
archives to see if I can answer this one myself.
===
From: scotth@sgi.com
To: Todd Lyons <todd@mrball.net>
Cc: Ivan Passos <lists@cyclades.com>, Rick Moen <rick@linuxmafia.com>,
Subject: Re: [svlug] Debian order of things
Date: 01 Mar 2001 21:33:42 -0800
>>>>> "T" == Todd Lyons <todd@mrball.net> writes:
T> Now for the next round of interesting stuff.
T> 1) Edited the deb line.
T> 2) apt-get install <snip>
T> 3) segfault installing binutils. says to run dpkg --configure -a.
T> 4) run dpkg --configure -a cuz nothing else works :)
T> 5) rerun apt-get install <snip> which pickus up from binutils and
T> completes successfully
T> It all runs properly, but it sure does seem strange that the binutils
T> install segfaulted. binutils did install properly when the apt-get was
T> rerun in #5. Ever seen this before?
The only time I've seen this is when apt and/or dpkg is being
upgraded. It gets about 1/2 installed and then trys to use the
incompatible new stuff. I've had to
dpkg --install /path/to/new/dpkg.deb
install it individually to work around the partially installed
problem. Took me a while to figure that one out, and I've worked on
installation software before!
T> I see references to unstable. I am using (apparently) stable. Do I
T> need to modify the deb lines again or do I need to alter my apt-get
T> commands? I've not looked much on this, so I'll scan through the SVLUG
T> archives to see if I can answer this one myself.
You change the deb lines in /etc/apt/sources.conf.
===
Date: Thu, 1 Mar 2001 23:57:28 -0800
From: Rick Moen <rick@linuxmafia.com>
To: World Domination <svlug@svlug.org>
Subject: Re: [svlug] Debian order of things
begin Todd Lyons quotation:
> It all runs properly, but it sure does seem strange that the binutils
> install segfaulted. binutils did install properly when the apt-get was
> rerun in #5. Ever seen this before?
I think Scott Henry is on the right track. Remember, you went directly
from the package versions in some 2.1 "slink" snapshot to those in the
current contents of the 2.2 "potato" mirror sites, on the Net: This
means you made a huge leap in the versions of everything all at once.
About "snapshots": Unlike most distributions, Debian is not
fundamentally defined by anyone's CD-ROM sets, but rather by the total
set of packages in the named branches (such as "slink', "potato", and
"woody") on the Debian Internet mirror sites, which sets advance
incrementally every day, as packages on them are updated. As a
convenience to CD-ROM vendors, at intervals a snapshot of a branch's
current state gets archived off and assigned a "release" number for that
snapshot of "Official Debian": 2.1r0 on 1999-03-09, and so on through
2.2r5 on 2000-03-23. On 2000-08-15, 2.1 "slink" was retired, the
ongoing 2.2 branch declared the new stable branch, and the 2.2r0
snapshot released. On 2000-12-05, most-recent "stable" snapshot came
out, 2.2r2.
(Note: The "release" sub-versions don't really mean diddly, except for
CD-ROM packagers. And you'll note that some vendors invent their own
snapshots of varying quality rather than using the "Official Debian"
ones, and even those who use the latter often don't label the disk
properly, because they want old inventory to remain saleable. Cheap
bastards.)
What you did was upgrade -- all at once -- your installed packages from
maybe 2.1r1 to _well_ past the 2.2r2 snapshot. (Remember, your apt-get
sessions upgraded all installed packages to the latest available on
_that day_.
Some smart-cookie commentators, such as the Linux Weekly News editorial
team, have at times been misled by the closeness of the "version
numbers" -- 2.1, 2.2, etc. -- failing to take into account that we're
talking almost a two-year development gap from 2.1r1 to 2.2-current.
And 2.1 actually got its start _long_ before March 1999 (as Debian's
then-current unstable branch).
Anyhow, given the huge leap in versions you took, I'm not surprised that
the upgrade bobbled a bit. If one thought about the problem in advance,
one might do this immediately after your first "apt-get update" and
before "apt-get dist-upgrade":
apt-get install dpkg perl libc6
That will bring those packages specifically up to current versions
_first_ (along with any packages they depend on), minimising your chance
of trouble in the big-upgrade step following. (I'd call those the three
most-crucial packages, generally.)
> I see references to unstable. I am using (apparently) stable.
You are, indeed. Your initial install, up to the point where you quit
dselect and halted the installation process, put in what was _once_
Debian-stable, i.e., some snapshot of 2.1 "slink". Then, you upgraded
directly to current-stable, that day's set of 2.2 "potato" packages.
Using an ftp client (not a Web browser), have a look at
ftp://ftp.debian.org/debian/dists/ . You'll see something like this
(trimming the non-essentials):
drwxrwxr-x 5 debian debian 4096 Dec 15 20:12 potato
drwxrwxr-x 5 debian debian 4096 Mar 1 20:48 sid
lrwxrwxrwx 1 debian debian 6 Feb 16 18:50 stable -> potato
lrwxrwxrwx 1 debian debian 5 Feb 16 18:50 testing -> woody
lrwxrwxrwx 1 debian debian 3 Feb 16 18:50 unstable -> sid
drwxrwxr-x 5 debian debian 4096 Mar 1 20:38 woody
Note that there are three named distribution branches, each with a
symlink pointing to it: stable = "potato", testing = "woody", and
unstable = "sid". The symlinks stable and unstable have always existed;
at any given time, they point to a pair of named branches, and the
symlinks get re-pointed when a branch is retired. On 1999-03-09,
the stable symlink was removed from "hamm" 2.0 (which then faded into
obscurity), and reassigned to "slink" (2.1). The "unstable" symlink,
in turn, was removed from "slink" (2.1) and re-pointed to a brand-new
experimental branch, "potato" (which eventually got assigned version
number 2.2).
This sort of changeover happened again on 2000-08-05: The stable
symlink was removed from "slink" (2.1) and assigned to "potato" (2.2).
The unstable symlink was removed from "potato" (2.2) and re-pointed to a
brand-new branch, "woody".
Very recently (mid-December 2000), we got an additional symlink,
"testing". (See: http://www.debian.org/News/weekly/2000/41/)
"testing" lets people try reasonably cutting-edge packages on
non-mission-critical Debian hosts, with reasonable hopes of not getting
cut themselves.
The point is that each symlink can be thought of as a "track". If you
specify "stable" in the applicable lines of /etc/apt/sources.list,
you're going to autmatically upgrade at some point (when you do apt-get
update; apt-get dist-upgrade) from potato to woody -- after The Debian
Project declared woody to be suitable to serve as the new unstable
branch, and changes the symlinks. By contrast, if you specify "potato"
there in place of "stable", you're saying you never want to continue the
incremental progress up onto new "stable" branches.
Personally, I stick with "stable" on my server, do "testing" on my
laptop, and leave "unstable" for those public-spirited souls willing to
follow the debian-devel@lists.debian.org mailing list religiously and
submit bug reports when their systems break.
I hope this helps you.
===