Bug#257747: Let 'I' (InstallSingle) pull in required upgrades
On Tue, Jul 06, 2004 at 01:23:16PM -0400, Andrew Pimlott <andrew@pimlott.net> was heard to say:
> On Tue, Jul 06, 2004 at 12:53:04PM -0400, Daniel Burrows wrote:
> > I had the impression you were complaining because "I" is doing
> > something different from "aptitude install foo"...but it really
> > is doing the same thing.
>
> I don't understand what you are saying. I gave an example of how they
> are not doing the same thing.
Maybe I don't understand what you're saying either :)
In every test I can run they do the same thing; in the code, they
perform exactly the same API call. The only way I can get the behavior you
describe is if I set the default release for "aptitude install", but not
for pressing "I"; as I explained below, this is expected behavior.
> > No. The problem is that release mixing is not handled well;
>
> I assure you: You can reproduce the behavior without mixing releases.
> I just can't give an example, because I'd have to wait until right
> upgrades are available. Here is an example scenario:
>
> - I have a pure unstable system with package p1 at version 1.
> - I 'u'pdate, and a bunch of new and upgraded packages are
> available. In particular, there is package p1 version 2, and
> package p2 that depends upon package p1 (>= 2).
> - I press 'I' on p2. It will show broken, because it needs a newer
> version of p1, but p1 has been placed on hold by 'I'.
I have never seen this behavior. I have seen un-upgradable packages
when p2 depends on p1 version 2 but p1 version 2 was not available.
> > apt only
> > looks at the default release when automatically resolving dependencies.
> > See, eg, #167398...or try the same thing with apt-get ("apt-get install
> > cream/unstable").
>
> That is one issue, but not the problem I am talking about. My issue is
> that aptitude refuses to un-hold packages implicitly put on hold by 'I'.
> I'm saying that the "hold" that 'I' puts packages on should mean "hold
> unless an explicit install/upgrade of another package requires it to be
> upgraded". (Or, it could be a new command, and 'I' could be left the
> same.
That's exactly what it means, and every test I've run confirms it.
The only time I've ever seen a package not be automatically upgraded is
when the upgrade is in a non-default release.
Just a thought, have you turned off the configuration option
"Automatically resolve dependencies of a package when it is selected"?
(that's Aptitude::Auto-Install in the configuration file) That would
produce the behavior you describe, because that option is only used in
the visual interface (it doesn't affect the command-line).
Daniel
--
/-------------------- Daniel Burrows <dburrows@debian.org> -------------------\
| You are standing west of a white house. There is a mailbox here. |
\----------------- The Turtle Moves! -- http://www.lspace.org ----------------/
Reply to: