[Gllug] Aptitude

[Peter Grandi]

>>> On Wed, 14 Sep 2005 00:10:35 +0100, Paul Cupis
>>> <paul at cupis.co.uk> said:

jack> Why would running "aptitude upgrade"

>> That's a rather dangerous thing to do. 'dist-upgrade' is well
>> defined, global 'upgrade' is a much fuzzier concept.

paul> Rubbish:

  man> upgrade Upgrades installed packages to their most recent
  man> version.  [ ... ] If a package cannot be upgraded without
  man> violating these constraints, it will be kept at its current
  man> version.

I would not put it as strongly as «rubbish» but this definition
is indeed rather problematic as «their most recent version» is
basically pot luck, both as which version is the most recent,
the dependencies thereof, and the quality status of the package.

However the quote above is a bit offtopic, because that is
'upgrade' as in the command line version of 'aptitude', but the
original poster was asking:

  > Why would running "aptitude upgrade" from the commandline
  > and running aptitude interactively, then pressing "g", do
  > different things?

Because just going ahead and relying on the interactive global
'upgrade' went a lot further than expected:

  > the second comes up with a bunch of fixes, removals,
  > upgrades, and the like, and generally gets tangled in
  > dependency hell.

To this my comment was that the interactive version offered an
opportunity for review, and because of this by default it is
rather more aggressive, unless one turns off some options.

As to the command line 'upgrade', that is not that safe either,
as whichever version is most recent for a package is indeed
rather fuzzy, and depends on the vagaries of which repositories
are listed in '/etc/apt/sources.list', how far the mirroring has
gone among the mirrors in the world, and transients like how
much of a ''collection'' upload is on a master mirror, and so
on. Also, is the most recent version known to work? Who knows...

Now, if all of the sources are guaranteed to be from the same
'stable'-state release then all forms of 'upgrade' are more or
less known to work, and the packages are more or less guaranteed
to be known to work, but this all depends on the premise.

For an alternative point of view, consider the case of a
security upgrade that involves a package and a dependency, and
that will be ''kept back'' by the 'upgrade' command but not the
'dist-upgrade' one...

>> Also, 'dist-upgrade' to a specifically named edition (eg
>> 'sarge') is rather safer than to a state (e.g. 'stable'),
>> because the association between editions and states is not
>> immutable.

paul> No, but it should be known at the time of running the
paul> command.

Ideally, but the original poster seemed to me to be unsure as to
which edition he was targeting...

  > Running Debian stable - I think I was on woody, then got
  > bitten by the upgrade, but not quite sure.

And if one is unsure, targeting explicit edition names and using
'dist-upgrade' is a bit safer than relying on pot luck.

paul> "upgrade" is much safer than "dist-upgrade" if you are not
paul> really paying attention,

It is «much safer» in a ''feeling lucky'' sort of way...

paul> and you can always set your source.list file to refer to
paul> the distribution/version by codename rather than by
paul> stable/testing/unstable.

Curious that this is said as if I had not written:

  >> also make sure all the paths in '/etc/apt/sources.list'
  >> mention exlicit edition names (eg 'woody', 'sarge', 'etch',
  >> 'sid' currently) instead of states, [ ... ]

as *part* of safer practices, not by itself, as leaving edition
control merely to the choice of paths in '/etc/apt/sources.list'
is a somewhat dangerous practice because it is quite easy to get
tempted into adding more sources later for occasional needs, and
then one ends having potluck 'upgrade' again.

Pinning (either variety) was introduced precisely because of
this only a few years ago, and admittedly some ''feeling lucky''
people disregard it...

Well, if one can guarantee that all sources are from well known
fast mirrors, they are all from the same 'stable' edition, etc.,
then things are easy and there are few pitfalls...

Myself, well, I don't believe in ''ideal conditions'' lasting
long, and I tend to assume that sources lists will be full of
dubious stuff, so I prefer belt-and-braces approaches, and not
relying on the ambiguity of «most recent version» and its
unknown properties seems wise to me. Bah!

-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug