martin f krafft

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!

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/+AbOIgvIgzMMSnURAookAKCm6vrzoi0CYEhfUSWqorSoKqyNpQ CfYoqc
n4sffVS04+MDwfXesi4QJRs=
=+Sob
-----END PGP SIGNATURE-----

travis crump

The testing/unstable version of aptitude supports 'aptitude -t testing
install ...'. Also, at this point in the release cycle, there is little
point in pinning stable/testing. If you use anything from testing, you
might as well just use testing completely since you'll be using mostly
testing libraries anyway.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/+MwxlxHEcbyY0skRAqQYAJ9Q0BRk4tVpqhKTedFJHDVFAAx1Hg CfdcF6
MsLkJKMncLrSA8jPCZhl7G8=
=M2RB
-----END PGP SIGNATURE-----

martin f krafft

also sprach Travis Crump <pretzalz@techhouse.org> [2004.01.05.0330 +0100]:

Thanks, this is good to know.

I still wonder why aptitude can't fulfill the dependencies.

If I have myapp=1.0 in stable and myapp=2.0 in unstable, and they
depend on libmyapp=1.0 and libmyapp=2.0 with versioned dependencies,
why does aptitude not just upgrade libmyapp when I ask it to upgrade
myapp, whether libmyapp=2.0 is in stable or unstable or whatever.

Debian's nice in terms of dependency handling, but this really only
applies to stable. I wonder why we don't accept the fact that a lot
of users run a total mixture, like a stable base, with packages from
testing and unstable as needed, and start thinking that way?

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFACDyuIgvIgzMMSnURApD6AJwKizIzdJ7ymzHmZvAVEL N7wV7KbgCfXR8M
q9HcE0D74T0debMe4PEOXxw=
=Vei3
-----END PGP SIGNATURE-----

colin watson

Because it's a total nightmare to support (i.e. construct consistent
dependency trees for) and doesn't really work properly as it is?

--
Colin Watson [cjwatson@flatline.org.uk]


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

martin f krafft

also sprach Colin Watson <cjwatson@debian.org> [2004.01.17.1124 +0100]:

Really? Here is an algorithm:

b = broken_package_count
foreach dependency:
if versioned:
automark specific version of dependency package for installation
if broken_package_count > b:
unmark version for installation
notify user of failure to automatically fulfill dependencies
else:
automark dependency package for installation

This would at least try to do its best. What are the problems with
it?

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFACvexIgvIgzMMSnURArqTAKDX3Mddk5QUCzOSOAC9zi 3XqKczmgCg4rEj
tSt24uOJOLwVyqUq8VVhVnw=
=uvX3
-----END PGP SIGNATURE-----