Re: Snofrix meta-packages
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 19-05-2005 11:01, Conrad Newton wrote:
> Although Snofrix is based on Debian/unstable,
> I suspect there would be no problem to use
> these meta-packages together with skolelinux
> sarge, also known as Debian/testing. Unlike
> the stable branch of Debian, unstable and testing
> are rather close to each other.
...for the time being, yeah. Expect things to change as soon as sarge is
released, though.
Do anyone besides me see a use for debtags here (as currently discussed
at debian-custom@ )? They wouldn't free Conrad from his tedious work of
selecting what can fit on his selected media, but if package selection
was stored as debtags-expressions for inclusions and exclusions, I
believe the list would survive longer than explicit package lists. And a
Snofrix-derivative being Gnome-centric instead of KDE-centric had an
easier job adjusting.
> Those of you who have been using apt-get all your life should
> learn about aptitude. When dealing with meta-packages of this
> kind, aptitude is a better tool to use, because of its intelligent
> handling of dependencies. For example, you install snofrix-cd-all,
> taking with you 500 new packages. Now you realize it was a mistake.
> If you type apt-get remove snofrix-cd-all, you will only remove
> the meta-package, and you will be stuck with 500 new packages.
> But aptitude cleanly removes all of the depencies, with a syntax
> that is essentially the same as apt-get: aptitude purge snofrix-cd-all.
This is almost true. In some corner cases packages are still left behind.
The exact logic is that aptitude removes packages when no longer
explicitly installed or depended upon (or recommended - see separate
note further down) by other installed packages.
Example: gimp-help-* depends on gimp-helpbrowser or the virtual package
www-browser. Installing gimp-help-en only pulls in gimp-helpbrowser -
and not even that if any other browser is already (to be) installed.
Installing gnome afterwards and then removing it, however, leaves behind
epiphany-browser or galeon pulled in but then kept hanging there because
they are providers of www-browser.
I am a big fan of aptitude and don't want to scare anybody off of using
it - your explanation is good as a sales pitch. The reason I get into
this detail is that it may save you some valuable bits to be aware of
this behaviour, especially as it sounds like you experimentally pull in
and remove again packages as part of composing your LiveCDs.
> There are occasions where you will still need apt-get however.
> Suppose you are using Debian/unstable, and you discover that
> gcompris has a critical bug that makes it unusable. You prefer
> to install gcompris/testing. But if you type aptitude remove gcompris,
> you will de-install snofrix-cd-all, and by consequence the entire system!
> Hence in this case you would use apt-get: apt-get remove gcompris
> followed by apt-get install -t testing gcompris.
I dislike your approach. Yes, removing and then installing again is
asking for trouble - so do the downgrade in one go instead. Personally I
use the full-screen mode of aptitude (invoke "aptitude" with no options)
and explicitly select the older version of gcompris I want (last lines
in package view), but I assume the following works from a commandline as
well:
aptitude install -t testing gcompris
Possibly apt-get will complain if the package is there already, but
aptitude deals well with downgrades (at least in fullscreen mode).
Oh, and the reason your metapackage gets uninstalled when removing a
single package it wants is that you depend on the wanted packages
instead of recommending them. Another reason to not abandon recommends
in addition to my note below!
> There are some additional issues with aptitude and recommended packages.
> I use a strict package accounting, because I cannot afford to have
> recommended packages installed on the CD behind my back. Hence my
> /etc/apt/apt.conf includes the line:
>
> Aptitude::Recommends-Important false;
>
> If you are not space constrained, and you want to have the recommended
> packages, you should change this value to true, or delete this line --
> I seem to recall that the default value is true.
Correct. It is actually a long-standing bug that apt-get does not pull
in recommended packages by default: Debian Policy 7.2 describes
recommended packages as to be installed "in all but unusual installations".
You are off course free to consider your liveCDs as "unusual" but
consider this: Often the difference between depends and recommends is
that lack of the first makes the package technically broken while lack
of the second "only" makes the package broken from an end-users point of
view!
Greetings,
- Jonas
- --
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
- Enden er nær: http://www.shibumi.org/eoti.htm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCjKGIn7DbMsAkQLgRAodqAJ0ejDrXRfzxrhjqVwEbxSN8EbuWHQCfU8cd
8Sh4mkvLKxbt2sIjOqK0Ut4=
=d8Z7
-----END PGP SIGNATURE-----
Reply to: