[SGVLUG] FC repository searches

[Mike Fedyk]

Dustin Laurence wrote:
> On Tue, Sep 12, 2006 at 05:04:49PM -0700, Jeff Carlson wrote:
>   
>> If dist-upgrade is only for upgrading between releases, then why is
>> there always something available to be dist-upgraded?  If the release
>> schedule is every 18 months, then it should only have something
>> available every 18 months.  That makes sense to me.
>>     
>
> The following is the best I can make out, though I know very well there
> are people on this list better qualified to explain Debian than me.
>
> No, but yes.  No, in that infrequently they will release a revision in
> between official Stable releases (I think there have been two for
> Sarge), and those can (I observe) require a dist-upgrade.  I think the
> last time I had to do a dist-upgrade for Debian Stable it was for a
> kernel bump that wasn't just a Debian patchlevel.  Other than that, the
> only things that come down the pipe are security updates.  That's what
> "Stable" means to Debian.  So, yes dist-upgrade should be infrequent for
> Debian *Stable*, though not actually 18 months.
>
> BTW, Slackware's security updates are the rarest I've seen, and when I
> first ran it I thought I wasn't getting updates because there were so
> few--I'm not sure how much of this is due to very conservative inclusion
> strategies and how much is due to having such a small distro in the
> first place.
>
> [Digression] There are (at least) two security patch strategies a distro
> can have, and which is chosen usually tells you a lot about the
> intentions of the packagers and what the maintenance experience is going
> to be like.  The Conservative strategy is that followed by, for example,
> Debian Stable (I suspect RHEL as well, and many other server-oriented
> distros).  Generally security upgrades are done by patching the exact
> package version that was released to guarantee the minimum disruption
> (for example, not bumping the upstream version generally means you don't
> need to touch /etc), backporting from a later upstream release if
> necessary, so that the upstream version number doesn't change, only the
> Debian patchlevel.  Sometimes this is impossible, of course, in which
> case it might be justified to bump the upstream version to close the
> security hole.  If this is disruptive enough, then it might take a
> dist-upgrade (which warns the sysadmin that this isn't something to do
> without thought at 4:50 on a Friday afternoon), and if possible Debian
> would rather roll several such upgrades together into a revision for
> convenience.
>
> This strategy works well for stability--I generally will do an 'upgrade'
> to my little server without worrying about breakage.  The only times I
> can remember this failing were when I didn't know enough to restart
> something that needed restarting (and usually apt-get does that for you
> too).  If I see packages held back, then I won't do them unless I'm
> ready to spend a bit of time (tweaking a config file in /etc, for
> example).
>
> The Aggressive strategy, followed by e.g. Gentoo (likely also Fedora,
> and I'm quite sure Sid does this effectively by simply having the
> current pool) is to prefer to bump the upstream version, if this will
> fix the security hole at hand.  This makes for a more up to date system,
> of course, but it also means more work for the sysadmin (because quite
> often /etc *does* need tweaked) and less stability (because obviously
> you're running a set of packages that have been less extensively tested
> together.
>
> I actually have a point--the distinction between 'upgrade' and
> 'dist-upgrade' is partly to help you know when Debian was unable to
> follow their preferred strategy of never changing an upstream version in
> Stable, and so you can schedule the upgrade at your convenience.  If one
> item needs a dist-upgrade I'm likely to assume it was a security patch
> that might require reconfiguration or something, but if there are a
> bunch of packages waiting all of a sudden, particularly if they are
> really critical packages, I might go and check to see if there is some
> sort of issue.  I am sort of lazy because my only Debian box right now
> is Sarge, and Sarge is the one that attempts to be bulletproof.  Running
> Sid would probably require me to monitor the news channels a bit better.
>   

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.  (There is some other 
package ordering and forcing differences between upgrade and 
dist-upgrade, but I do not know the details)

The reason this works well for debian is because they split their source 
packages into many different binary packages.  So if a package suddenly 
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.  The nice thing is that you can install an updated kernel with 
apt-get upgrade and it won't break any modules you have compiled against 
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.  With that said, so far there have been two 
updates in Debian Sarge where recompiling those out of tree modules was 
required but that number is kept to a necessary minimum.

* Partly because the different name creates a new directory in 
/lib/modules/`uname -r`/ where ABI compatible modules are stored.

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

Mike