Comment 3 for bug 75332
Revision history for this message
|
|
#3 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
513534c
demo site
(Get the code!)
On Sat, May 04, 2002 at 12:17:32AM -0400, Faheem Mitha <email address hidden> was heard to say:
> b) that if you put a package (say foo) on hold in the traditional way,
> # echo "foo hold" | dpkg --set-selections
> this is completely ignored by aptitude.
Could you give me a reproducible test case? This has always worked
for me.
> Currently, aptitude stores the held status of packages in some
> internal database. I am guessing this may be
> /var/lib/
> apt-get, ie. reading information from /var/lib/
No, it wouldn't. dselect's states are not in general equivalent to
aptitude's, although they're similar.
> I see that you responded to Joey Hess's report saying the bug had been
> fixed, but it is still open, and I certainly see the behaviour he
I think it was a typo, sent to the wrong bug. Another joeyh bug
filed at about that time was describing something that had been fixed.
> The behaviour of aptitude using its own hold is similar, except that
> it does not warn about the package having being in the held state. (It
> might be a good idea to add a warning as apt-get does). This might be
> called a "softer hold". :-)
That might be nice.
> I would like to see a "hard hold", where short of explicitly unholding
> the package, the package will not be upgraded. This would make it
> unlikely that you would accidentally nuke a painfully hand-compiled
> (over several hours) package :-) Perhaps you could put a config
> option, to toggle the behaviour of aptitude between a "soft" and
> "hard" hold.
That might also be nice.
> Are you planning to work actively on aptitude over the summer?
It depends on how much I'm working this summer. I don't know yet.
Daniel
--
/------
| After the game, the king and |
| the pawn go in the same box. |
| -- Italian proverb |
\------