proper use of aptitude in stable/unstable mixed systems

From: martin f krafft (madduck_at_debian.org)
Date: 01/04/04

  • Next message: Antonio Rodriguez: "Re: locales and coding systems"
    Date: Sun, 4 Jan 2004 13:27:58 +0100
    To: debian users <debian-user@lists.debian.org>
    
    
    

    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!
    
    

    -- 
    To UNSUBSCRIBE, email to debian-user-request@lists.debian.org 
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
    


  • Next message: Antonio Rodriguez: "Re: locales and coding systems"

    Relevant Pages

    • Re: Linux Vs. FreeBSD
      ... >> has made a lot of effort towards making it easy to install. ... Debian's not a bad distro. ... although packages like this are few and far between. ... since the binary dependencies certainly wouldn't be any ...
      (comp.os.linux.misc)
    • package management begins to annoy me
      ... is only because i don't know apt-get and aptitude well enough. ... aptitude has the nice feature of marking packages that are install ... I wanted to upgrade the already installed CD ...
      (Debian-User)
    • Re: Noob question - best way to install software
      ... I am wondering about the best way to install software. ... Aptitude is supposed to do everything that apt-get will do ... installed to meet dependencies of packages that you specifically wanted ... Since you're new to debian, I suggest you read: ...
      (Debian-User)
    • Re: Administration (+apt-get dist-upgrade) of 100s of machines
      ... "suggested/recommends" as it installs other packages. ... Hence the "aptitude deleted all my files"-type posts ... Install Debian 4.0 "Etch". ... The Pentium running sid 173MB worth of changes: mostly KDE changing as ...
      (Debian-User)
    • RE: FC5 - T3 - Had enough. Package Managers, Yumex is crap.
      ... install/update a huge number of packages would stress things out too ... Run "yum update yum". ... Say FC4, where you install it new, then ... dependencies, something that is a major bugbear in Linux that I've not ...
      (Fedora)

  • Quantcast