[SGVLUG] FC repository searches

[Dustin Laurence]

On Tue, Sep 12, 2006 at 06:43:23PM -0700, Mike Fedyk wrote:
> 
> The main difference between upgrade and dist-upgrade is that upgrade 
> skips installing any new packages on your system and any packages that 
> now depend upon those uninstalled packages.

I'd sort of forgotten that distinction.

> The reason this works well for debian is because they split their source 
> packages into many different binary packages.

This is an excellent point I forgot--Debian splits their packages more
finely than any other distro I've ever seen (which does make it a bit
disingenuous to brag about the number of packages in the pool).  One
upstream tarball often becomes two or more .debs.  This is very, very
nice when installing on decrepit hardware with a tiny hard drive (I used
to know how much the minimal standard Sarge install was, I think it was
of the order a couple hundred Mb but that sounds amazingly low so
perhaps I misremember), but slightly annoying when you are compiling
yourself from source on Debian the first time.  The dance goes like
this: need libfoo, ok, apt-get foo.  Oops, still doesn't build, I need
the foo headers because I'm compiling, why aren't they there?  <does a
file-level search with the web or apt-file for foo.h>  Ah, I see,
headers are only needed for development, so apt-get foo-dev.  OK, what
is this function doing, need the docs, why didn't they come with
foo-dev?  Ah, got it, apt-get foo-docs.  Oh, I need some of the
non-essential helper scripts and such, apt-get foo-extras.  Actually
this isn't too bad once you're used to it, and it gives you a lot of
control, but the first time you have to install all that where other
distros would have packed it all into one or two larger packages, it's
frustrating.  Later you tend to know to just get foo and foo-dev
immediately if you're building against foo, and more generally to look
in advance at all the foo* packages to see what you need.

I hadn't ever thought about it being linked to their upgrade strategy,
though.  It makes a kind of sense, but how exactly do you figure the
many-small-packages strategy helps with upgrade vs. dist-upgrade?

> depends on a package you don't have in your system, apt-get upgrade will 
> skip installing the new package and hold back any packages updates that 
> depend on uninstalled packages.
> 
> The debian kernel package is a prime example to show the difference 
> between upgrade and dist-upgrade (that said, the kernel is a special 
> case in debian packaging strategy*).  The latest Debian sarge kernel 
> package name is 2.6.8-3-$arch and the package version is 
> 2.6.8-16sarge4.  It used to be 2.6.8-2-$arch but a security update 
> required an ABI change, so a new package name was used to show this 
> fact.

Are you sure that's the main reason?  I thought the Debian patchlevel
changed whenever the package got changed in some way--are you saying
that a trivial, guaranteed-not-to-break update to X.Y.Z-W might also be
X.Y.Z-W?  I hadn't noticed that.

> any previous kernel release of the same package name.  Compare this to 
> RHEL and Fedora where every kernel update gets a new package name and 
> ABI changes are not tracked at all.  Updated kernel, recompile all of 
> your out of tree modules.

Ah, I see--I've not done as much kernel compiling under Debian, so I
thought it used the latter rules.

> The reason why upgrade and dist-upgrade is used differently is mostly 
> because of the packaging style of the debian project.  Installing new 
> packages, or packages that depend on packages you don't already have is 
> a lot more risky than just updating packages you already have installed.

I'm still trying to figure out how this is connected to the very
fine-grained package system, since what you say would be true whether
the packages are fine-grained or not.

> I have to contradict what Distin said about needing a dist-upgrade 
> "partly to help you know when Debian was unable to follow their 
> preferred strategy of never changing an upstream version in Stable".  
> Firefox is an example where upstream is followed quite closely by the 
> debian security team, but the name of the package doesn't change so you 
> wouldn't need a dist-upgrade to update it unless it suddenly depended on 
> a new package you don't have installed.  That said, Distin is pretty close.

Are you sure about that?  I just checked one of my up-to-date Sarge
systems and it still has Firefox 1.0.4.  I'm taking that from "firefox
--version", not the package name.  It also violates the stated stable
policy.  I bet you have Debian backports in your sources.list (come to
think of it, I probably should on that machine too, since it isn't a
server), that's supposed to be the only way to continually track a
package on stable.  (I forgot to mention backports, but I suppose it
only confuses the issue.)

In fact, I just checked and FF has an updated package, still 1.0.4 but
with an upgraded Debian patchlevel.  That seems like what I described,
so I do think  non-kernel packages work this way.

Dustin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.sgvlug.net/pipermail/sgvlug/attachments/20060913/0fb3f479/attachment.bin