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

Bug#257747: marked as done (apt only looks at the default release to resolve Dependencies)

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 owner@bugs.debian.org
immediately.)


-- 
167398: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=167398
Debian Bug Tracking System
Contact owner@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 Kalnischkies

Attachment: signature.asc
Description: Digital signature


--- End Message ---
Reply to: