Prev: dash-as-bin-sh
Next: How does snapshot.debian.org work?
From: Boyd Stephen Smith Jr. on 27 Apr 2010 11:30
On Tuesday 27 April 2010 08:48:48 Daniel Burrows wrote:
> aptitude's resolver will *still* upgrade held packages

Oh noes!

> A temporary solution for you is to cancel the auto flag on any
> package you hold.

Simple enough.

> Long-term solutions in the code could include postponing dependency
> resolution until after the resolver finishes (which could have
> wide-ranging implications), refusing to remove unused held packages, and
> somehow "remembering" the held flag on packages that were removed
> because they were unused.
>
> Of these three solutions, I prefer the second one, refusing to remove
> unused held packages. It fits in with the intuitive meaning of "hold",
> it's easy to implement, and it doesn't have a high risk of surprising
> side-effects, since it only affects a fairly precisely defined set of
> packages.

As a user, I also prefer that approach, for all the reasons you mention.

> Essentially, it causes held packages to be added to the root
> set (and that's the best implementation, I think: modify aptitude's
> custom root set function to include held packages).

You lost me, but I haven't delved into the aptitude source code. My approach
would have been just making the 'hold' action also clear the 'automatically
installed' flag; essentially "institutionalizing" the temporary solution.
But, I defer to your solution as it sounds more flexible.

$(reportbug -k aptitude)
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss(a)iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
From: Daniel Burrows on 28 Apr 2010 01:20
On Tue, Apr 27, 2010 at 10:32:25AM -0500, "Boyd Stephen Smith Jr." <bss(a)iguanasuicide.net> was heard to say:
> On Tuesday 27 April 2010 08:48:48 Daniel Burrows wrote:
> > Essentially, it causes held packages to be added to the root
> > set (and that's the best implementation, I think: modify aptitude's
> > custom root set function to include held packages).
>
> You lost me, but I haven't delved into the aptitude source code. My approach
> would have been just making the 'hold' action also clear the 'automatically
> installed' flag; essentially "institutionalizing" the temporary solution.
> But, I defer to your solution as it sounds more flexible.

That's just a complicated way to say "pretend held packages are
manually installed". It's important to do this and not just refuse to
remove them because their dependencies should stay on the system too.

Daniel


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/20100428051054.GB2540(a)emurlahn.burrows.local
From: Daniel Burrows on 29 Apr 2010 00:10
On Tue, Apr 27, 2010 at 09:59:19AM -0600, "Monique Y. Mudama" <spam(a)bounceswoosh.org> was heard to say:
> I use "hold" liberally to weather Sid storms. There are two cases I
> see crop up: one, aptitude suggests removing packages without an
> obvious replacement. Two, aptitude marks things as broken that have
> been working just fine. In either case, I start slamming the "=" key
> until packages will no longer be removed, and nothing is marked
> broken. This works 99.99% of the time. At some later period when I
> suspect the storm has passed, I test the waters by unholding the
> packages and gauging aptitude's reaction.

With aptitude 0.6.2+, I'd be curious to know whether you get the
answers you want (with less removals and less need to manually hold)
with this setting or something like it:

Aptitude::ProblemResolver::SolutionCost="2*removals + canceled-actions,safety,priority"

(sorry about the long line)

That will ask aptitude to minimize the number of removals and canceled
actions, but to weigh removals as being twice as bad as holding packages
back.

> If this is a misuse of "hold" and there's a better way, though, I'm
> all ears. Rereading, it seems like "forbid-version" would be the
> right call for most of what I'm doing, assuming it does persist
> between aptitude sessions.

Forbid-version is probably more appropriate, yes.

Daniel


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/20100429040704.GA10998(a)emurlahn.burrows.local
First  |  Prev  | 
Pages: 1 2
Prev: dash-as-bin-sh
Next: How does snapshot.debian.org work?