[TriLUG] Debian operaton.

Neil Roeth neil at occamsrazor.net
Tue May 27 21:46:36 EDT 2003


On May 26, Bill Gooding (bgood210 at yahoo.com) wrote:
 > >> 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.
 > 
 > I'll stick with my original argument on this one. 
 > Your tautology is well taken though.  We can agree to
 > disagree.  It may be that after using Debian for a
 > little while I may interalize their terms and wonder
 > how anyone would think any different.  Of course, all
 > someone would have to do is dig up my original post
 > and embarass me if I harassed them on the point :-)

I actually _agree_ with you about the terminology; I see your point
about how it might be confusing.  Like most Linux things, there's a
nontrivial learning curve, so what is second nature to an experienced
Debianite is not necessarily clear to a neophyte.  I doubt the
terminology will change anytime soon, though, so you'll probably just
have to grin and bear it!  :-)

BTW, the "slight bias" comment is facetious - I've been using Debian for
years, and I maintain a few Debian packages.

 > > 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.
 > 
 > I am just posting Neil's comments on this.  He is
 > completely right here, and my method is wrong.  I am
 > just going to elaborate a little on what he said
 > describing what I think is an accurate view of the
 > reasons for this.  In the Debian binary packages, they
 > seem to create alot of dependencies.  In particular,
 > the binary package depends on the software used to
 > compile it among other things.  I kind of implicitly
 > thought that the dependencies would only be those
 > necessary to run the software not the systems it was
 > actually compiled on.  I figure that most compiled
 > programs will run OK on different systems.  I don't
 > think they are that different.  Most programs for
 > Linux are C and I would think a C program compiled on
 > Debian 2.0 would run on Debian 3.0.  And I thought
 > that they would express this in the dependencies.  But
 > what they seem to do is express the dependency based
 > on how they actually compile not where it might
 > actually run.

There are two kinds of dependencies: dependencies and build
dependencies.  The former is what you thought it was: what is required
to run the package; the latter is what is required to build it.  A C
program compiled on sid will run on woody, but it may depend on a set of
newer shared libraries, so when you install the package, it will install
all of the newer libraries, too.  Installing some package foo which uses
Perl/Tk might install a newer version of Perl, a newer version of Tk,
and newer versions of the libraries those depend on, etc.  This is a
Good Thing in that it means you will not encounter a failure running foo
because of a missing library or other package, but it means that you
potentially have to install a lot of prerequisite packages.

 > So for operating Debian, Neil is completely right.  In
 > general if you are running version K of Debian, only
 > get binaries for version K+1.  So for example if you
 > are running Debian 2.0 (potato), have binary package
 > entries for 3.0 (woody).  If you want a more recent
 > package say from 5.0 (sid), compile it from sources,
 > and it will most likely work unless they are using
 > some new feature.  Then you would just be out of luck
 > or you could manipulate the source code/fix the
 > problem.  If you want to be extra safe about the
 > distribution you are running, you could also just
 > compile from all packages not in your current
 > distribution (i.e. just have sources.list entries for
 > version K of Debian)
 > 
 > The original reason I wanted to run the system like I
 > suggested was just to get bleeding edge copies of some
 > of the software I commonly use.  I was going to keep
 > the system at woody (3.0), and download sid (5.0)
 > binaries.  Doing this did what Neil said it would.  He
 > was about a day late in stopping me from shooting
 > myself in the foot :-).  But seriously, it really
 > wasn't that bad or anything.  But now I am running
 > testing/unstable as opposed to all three.  

What you were attempting is possible, up to a point, but as you found
out, you eventually have a system that requires as much or more work to
maintain than a pure sid (unstable) system.  So, you might as well run
unstable.  (Sorry about being a day late!)

 > Another thing I noticed was that after upgrading to
 > testing, I did apt-show-versions and some of the
 > packages were still marked stable.  I think it's just
 > that some packages don't change and keep their
 > original markings.  I am not going to worry too much
 > about that.  And I checked the package archive and
 > what I have matches what they have (at least for a
 > sampling of the packages).  BTW, if you are using
 > Debian, the package archive is a very useful tool -
 > http://www.debian.org/distrib/packages.  It tells you
 > the packages available and it also has a method to
 > tell you what files are owned by what packages.  I'm
 > sure you can do this in apt too, but sometimes a
 > package might refer to a file that you don't know
 > about.  The internet package site is very conveinent
 > for figuring out these things (if you made the mistake
 > I did).

That's a good suggestion.  I would also suggest using apt-cache, e.g.,
"apt-cache search foo" to find all packages that have something to do
with foo.  This uses information downloaded by the apt-get update
command, so it can be done offline.  It will not give you all the
information that you can get from the web page, but it suffices in many
cases.

 > Too bad I can't change my original post.

It was excellent, I'm glad you posted it.

-- 
Neil Roeth



More information about the TriLUG mailing list