[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

proper use of aptitude in stable/unstable mixed systems



Dear all,

I have been using aptitude for a while now and prefer it greatly to
dselect when it comes to making custom changes to the installation
base of my various systems. All these systems run a mixture of
stable/testing/unstable, and I use pinning to set the default to
either stable or testing. This allows me to maintain a stable or
testing base system, but when there's a package in unstable that
I need, I can pull it in along with its dependencies.

This works, but that's about all. Whenever I need to pull in
a package from a "higher" archive (where unstable > testing > stable),
I need to fulfill all dependencies manually. So where has Debian's
feature of automatic dependency management gone? I am not running
RedHat...

Here a concrete example:

A machine is running stable with a bunch of unstable packages (e.g.
libc6). Among the installed packages is logcheck:

  ii  logcheck       1.1.1-13.1     Mails anomalies in the system log

  logcheck:
    Installed: 1.1.1-13.1
    Candidate: 1.1.1-13.1
    Version Table:
      1.2.15 0
          99 http://sunsite.cnlab-switch.ch testing/main Packages
          98 http://sunsite.cnlab-switch.ch unstable/main Packages
          99 http://ftp.de.debian.org testing/main Packages
          98 http://ftp.de.debian.org unstable/main Packages
  *** 1.1.1-13.1 0
          700 http://sunsite.cnlab-switch.ch stable/main Packages
          700 http://ftp.de.debian.org stable/main Packages
          100 /var/lib/dpkg/status

Due to a bug and some features, I would like to update logcheck to
the testing version, 1.2.15. To achieve this, I can do one of three
things:

  1. apt-get install logcheck/testing
  2. aptitude install logcheck/testing
  3. manually upgrade logcheck in aptitude's UI
  4. apt-get install -t testing logcheck

The forth method is the only one that does the job since it changes
the pinning to favour unstable. The other three methods fail to
install the unstable version of logcheck because they cannot fulfill
the dependencies:

  E: Unable to correct dependencies, some packages cannot be installed
  E: Unable to resolve some dependencies!
  Some packages had unmet dependencies.  This may mean that you have
  requested an impossible situation or if you are using the unstable
  distribution that some required packages have not yet been created
  or been moved out of Incoming.

  The following packages have unmet dependencies:
    logcheck: Depends: logtail (= 1.2.15) but it is not installable
              Depends: logcheck-database (= 1.2.15) but 1.1.1-13.1 is to be installed.
              Depends: debianutils (>= 1.16.9) but 1.16.2woody1 is installed.
              PreDepends: logtail (>= 1.1.9.1) but it is not installable

However, all of these dependencies are in testing and fulfillable,
when I tell aptitude to install them manually, or add them to the
command lines of aptitude or the first apt-get method, the
installation proceeds as requested (after two or three iterations of
fulfilling dependencies manually).

I can kinda understand why aptitude doesn't do it, and why `apt-get
install -t testing` is the only way to achieve the goal. However,
then again I don't. The above output from aptitude is plain wrong
and all the information necessary to fulfill the dependencies are
there. So why not just fulfill them, rather than providing false
information?

I'd be interested in how other people think about and solve this
problem.

Cheers,

-- 
Please do not CC me when replying to lists; I read them!
 
 .''`.     martin f. krafft <madduck@debian.org>
: :'  :    proud Debian developer, admin, and user
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!

Attachment: pgpaTGw93k0AB.pgp
Description: PGP signature


Reply to: