Re: Bug#167398: selecting packages via depends relations, esp. with versioned deps
On Fri, Nov 01, 2002 at 10:02:28PM -0700, Jason Gunthorpe wrote:
> PJC <peter@llama> 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.
I was afraid of that. Even though it is apt's designed behaviour, and thus
not a bug, I still think it's a bit of a problem that apt isn't nicer about
installing things from unstable.
Maybe instead of saying there is an error: Broken packages, apt-get should
tell you to use -t unstable and try again if you are trying to install
foo/unstable. It takes some knowledge of apt to figure out that saying -t
unstable is a good thing to do here, but using the odd package from unstable
to help test things out is something that should be as easy as possible for
beginning to intermediate users.
> 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..
So, I, er, found a "feature" in apt :) hehe.
>
> 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.
Yes, that's a good way of putting it. My main concern at this point is
ease of use for new users with a stable system wanting to install the
unstable version of something, or a new package that's only in unstable.
(That often requires libc/unstable, so it's not for total newbies, of
course.) The Debian Desktop project (announced recently, and mentioned in
DWN) makes some good points about trying to make small parts of the system
understandable without knowledge of the whole thing.
If nobody can thing of something good to do about all this, then it's not a
tragedy if we don't do anything. Things aren't all that bad the way they are.
> That's actually quite algorithmically challenging :|
Really? What goes wrong if you:
foreach dependency{
does version from default release satisfy? yes->ok, we're done
considering all available packages from non-default releases, take the
highest priority one which satisfies the dep, else fail.
}
Is there a problem because of conflicts and versioned dependendencies from
other packages? I could image things might get hairy with a web of
interlocking conflicts and depends (esp. with <= and >= versioned conflicts
and deps). I need to go to sleep RSN, so I'll take your word for it that
it's non-trivial in the general case.
>
> Since aptitude doesn't have the option of doing the same as '-t' for a
> single run something is going to have to be done to have a nice UI, but
> I'm not entirely sure what is best..
Like I said, fixing the actual bugs in aptitude makes it fairly useful for
manually selecting deps that apt won't install automatically.
happy hacking,
--
#define X(x,y) x##y
Peter Cordes ; e-mail: X(peter@llama.nslug. , ns.ca)
"The gods confound the man who first found out how to distinguish the hours!
Confound him, too, who in this place set up a sundial, to cut and hack
my day so wretchedly into small pieces!" -- Plautus, 200 BC
Reply to: