Your message dated Fri, 14 Aug 2015 22:20:41 +0200 with message-id <20150814202041.GA24448@crossbow> and subject line Re: Bug#167398: selecting packages via depends relations, esp. with versioned deps has caused the Debian Bug report #167398, regarding apt only looks at the default release to resolve Dependencies to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 167398: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=167398 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---Package: aptitude Version: 0.2.15-1 Severity: wishlist The command-line version of aptitude, like apt-get, is pretty smart: If you ask for a package with the "install" command, it will pull in just the set of packages and upgrades needed to install that package, keeping back everything else. This is a really useful policy, even more so when using --target, because it minimizes the set of packages from the target release. There doesn't seem to be a way to get the same effect in interactive-mode aptitude. The 'I' (InstallSingle) command is similar to this, in that it will pull in required new packages, but it won't pull in required upgrades; you have to go and find them yourself. It would be nice if 'I' (or a different command) ran the same algorithm that "aptitude install" uses. This would in my opinion be a big step forward for managing upgrades and mixed-release systems, as well as removing an awkward trade-off between command-line and interactive-mode aptitude. Andrew PS. Another nice feature for mixed-release systems would be a way to switch the target release from within aptitude. -- System Information: Debian Release: 3.0 APT prefers unstable APT policy: (600, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.7-1-686-smp Locale: LANG=C, LC_CTYPE=C Versions of packages aptitude depends on: ii apt [libapt-pkg-libc6.3-5-3 0.5.25 Advanced front-end for dpkg ii libc6 2.3.2.ds1-13 GNU C Library: Shared libraries an ii libgcc1 1:3.3.4-2 GCC support library ii libncurses5 5.4-4 Shared libraries for terminal hand ii libsigc++-1.2-5c102 1.2.5-1 Type-safe Signal Framework for C++ ii libstdc++5 1:3.3.4-2 The GNU Standard C++ Library v3 -- no debconf information
--- End Message ---
--- Begin Message ---Version: 0.8.11 On Fri, Nov 01, 2002 at 10:02:28PM -0700, Jason Gunthorpe wrote: > > It's a general problem, not at all specific to tubesock. It happens any > > time I'm installing a package that has dependencies that can't be satisfied > > from stable. I've already got tubesock/unstable installed, so I need to > > find another package who's unstable version has unsatisfied deps from > > unstable... > > It isn't actually a problem. It is doing exactly what you asked: > > apt-get -t stable install nessus/unstable > ... > nessus: Depends: libnessus1 (>= 1.2.5) but 1.0.10-2 is to be installed > > Which translates exactly into: 'use the stable version of all packages, > except nessus'. So there is no bug here.. > > What you want is some new feature that tries to find a set of required > packages such that the minimum number of other packages are moved to > non-default verisons. That's actually quite algorithmically challenging :| This is indeed challenging, but for a while we at least try a little harder for requests like the one above or more specific like: apt-get install nessus/unstable This will set nessus to unstable and also all versioned dependencies it has which are not statisfied in the default release, but are in unstable, so the feature requested here is implemented, hence closing as done. Best regards David Kalnischkiessignature.asc
Description: Digital signature
--- End Message ---