[TriLUG] Debian operaton.

[Bill Gooding]

Hi,

This post is just in response to Neil's comments, he
pointed out a fairly major error I made and I just
wanted to admit that he's right on this.  

As a side note, I sometimes wish that there was an
include file for all posts on a list (like #include
<std_dislaimer.h>).  It would include things like the
following:

/* 
This is just free speech feel free to ignore it or
move to to some country that lacks it if you prefer.
Sometimes written communication is imprecise and can
be misinterpreted, so don't take anything too
seriously.
These are just my views, I could be wrong, make sure
you agree with any justifications given.
Justifications are as important as the advice.
As always, draw your own conclusions based on logic
and evidence.
If you want to violate the previous point and make up
conclusions randomly, why bother reading anything and
pretending to debate it.
....
*/

This header would come in handy, then I wouldn't have
to make disclaimers or arbitrarily soften things
everytime I write something.  So anytime I write
something, remember that I meant to include
std_disclaimer.h even if I don't.  And look at the
followup posts they make some good points.

Much of what Neil said is either a better or
equivalent wording to what I gave.  I'll just respond
to 3 things.


 >> 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.

Yes, that's right.  My statement just gave sufficient
conditions.  Yours look like they are necessary and
sufficient.


>> 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 :-)


> 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.

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.  

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).

Too bad I can't change my original post.


Later,


Bill Gooding



__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com