On Fri, Dec 12, 2008 at 06:38:15PM -0500, Eben King wrote:
> On Fri, 12 Dec 2008, Paul M Foster wrote:
>
>> On Fri, Dec 12, 2008 at 01:28:05PM -0500, Eben King wrote:
>>
>> <snip>
>>
>>> Can dist-upgrade _only_ take me to Debian (which version?), or can it do
>>> other things as well? How does it decide?
>>>
>>> I use a custom-compiled kernel. I guess backing it up, then letting
>>> apt-get do its thing, then restoring it, should do the trick.
>>
>> Where dist-upgrade takes you to depends on your apt config file. If
>> you're running on, say, Potato, and you do a dist-upgrade, it will bring
>> you up to whatever is the current stable (Etch?).
>
> What are their relative positions?
>
Well, I don't recall the exact names of the distros. Debian has this
silly scheme of naming their stable releases after characters in the
movie "Toy Story". But in general, there are three distros at one time
with Debian: stable, testing, and unstable. New software and
significantly changed software comes in at unstable. (Actually, unstable
is a misnomer. The unstable distro is probably more stable than n.0
release of Fedora or Red Hat.) When they can say for sure it doesn't
cause leprosy on contact, it gets shoved into testing. At some point, it
gets pushed down to stable. Once every few years, when everything looks
perfect and there no sunspots or high winds, they package stable up and
create a new "release". And it gets its Toy Story name.
I was a little imprecise when I talked about the "apt config file". It's
actually /etc/apt/sources.list. In that file, you'll find a line or
lines like:
deb ftp://ftp.us.debian.org stable main contrib non-free
The word "stable" there can be changed to "testing" or "unstable", or
you can have one line for each of the three. The "main contrib non-free"
part specifies the parts of a given distro you want to track packages
from. I'm fuzzy on their exact differences, but you can infer that
non-free contains software that Debian's free software guidelines won't
let them put in the main repository.
In any case, changing the "stable" word to something else causes
anything like apt-get install, apt-get update or apt-get dist-upgrade to
reach out to update the local apt database to reflect the packages which
are current for the distro you've chosen. You could theoretically have
something like kde-base 2.67 in stable, kde-base 3.2 in testing, and
kde-base 4.01 in unstable, just as an example of one package. So if
you're on testing and you issue a "apt-get install kde-base", you'll get
the 3.2 version if your local database is up-to-date.
To be more precise, when you issue a command to install or upgrade a
package, you'll just give apt a package name. Apt then looks at its
local database, which also contains the number of the most current
release for your distro (stable, testing, unstable), as of the last time
you updated your local database. Long-term Debian users have all
attempted to install a package, and been told by apt that it can't
install that package. The reason is that your local apt database has a
version number for that package that's no longer contained in the online
repository. For example, you want to install mutt, and the version
number for that package in your local database is 1.5.15. But that
version has been superceded in the online repository for stable (or
whatever). Online, it's now mutt 1.6.21 (for example). So you have to
perform an apt-get update to refresh your local database. Afterward, the
version number for mutt points to 1.6.21, and the next time you issue an
apt-get install mutt command, it will happily fetch that version from
stable (or whatever).
>> However, if you change your apt config to track testing or unstable, it
>> will bring you all the way up to the current testing/unstable (with the
>> resultant chaos).
>
> Are they the same, or is one more refined than the other? How do I change
> the "track"?
"Tracking" is just slang for maintaining your Debian installation at a
given distro level, stable, testing, or unstable. And that's governed by
what's in your sources.list file.
<snip>
>
> I wrote a script that runs "make menuconfig", files away the .config after
> letting you name it, compiles the kernel and modules, and installs them. I
> got burned by needing to go back two steps and didn't have a way. Now I
> do.
Exactly the thing to do. Kernel compilation is really simple, as long as
you do something like this. The kernel is designed not to blow up when
you try to recompile it. The kernel folks are pretty fair programmers
;-}.
Any other questions, feel free. This is kind of complex, and I may not
have explained it as well as I could have.
Paul
-- Paul M. Foster ----------------------------------------------------------------------- This list is provided as an unmoderated internet service by Networked Knowledge Systems (NKS). Views and opinions expressed in messages posted are those of the author and do not necessarily reflect the official policy or position of NKS or any of its employees.
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 18:03:08 EDT