[Aptitude-devel] Здравствуйте

2016-05-25 Thread Люсьена1944 
___
Aptitude-devel mailing list
Aptitude-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel

[Aptitude-devel] Bug#825290: aptitude: (h)old packages should need to be specifically "unhold" to accept further actions on them

2016-05-25 Thread Christoph Anton Mitterer 
Package: aptitude
Version: 0.8.1-1
Severity: wishlist
Tags: upstream


Hi.

Currently, when I mark a package as hold (= key in the UI) it will get the
hold status, which is however automatically overridden, when I e.g. do a
"+" for upgrade on the package or the whole collapsed tree element.

I think this makes the behaviour quite unfortunate as it easily happens
that the "hold" flag is automatically overridden, e.g. just by saying
"upgrade all".

It would be nice, if a hold package needs to be specifically "unhold" first
before other actions like upgrade/remove/purge/etc. would be accepted on
it.

To make thinks easier to work with:
- there could be UI and/or command line options that allow to
  - simply ignore this one time
  or
  - clear
  any hold flags on packages.
- The action overview could feature a special section which features all
  packages (either marked as hold or not), which are kept in the current
  state *because of* the hold flag on some packages.
  E.g. *other* (non-hold) packages which are not not auto-upgraded or not
  auto-removed or hold packages that are not upgraded/removed/etc. (even
  though the user tried to perform the action on them) because of the flag.


Cheers,
Chris.

___
Aptitude-devel mailing list
Aptitude-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel

[Aptitude-devel] Bug#816781: aptitude: Can not cancel pending upgrade actions

2016-05-25 Thread Andrei Demekhov 
On Sat, 5 Mar 2016 14:36:00 + "Manuel A. Fernandez Montecelo" 
 wrote:

2016-03-05 14:10 GMT+00:00 å¼  敬强 :
> 在 2016年3月5日星期六 CST 下午1:00:25，Manuel A. Fernandez 
Montecelo 写道：
>> The behaviour has been changed recently, so that when one goes ahead
>> with the installation, the state is saved to more places than aptitude's
>> internal state (e.g. dpkg), on which other tools feed.
>>
>> Since some parts of this state cannot be undone, and since there were
>> other problems associated with this (e.g. removing "hold" state which
>> had been set in previous sessions), "Cancel pending actions" has been
>> changed in 0.7.6 to just cancel pending (as in "not confirmed/saved")
>> actions, rather than marking all packages as "keep" and destroying other
>> things in the way.
>>
>> Perhaps we should change the name of the menu entry to reflect the
>> change of behaviour, but sadly the name fits much better the new
>> behaviour, and the previous behaviour's menu entry should have been
>> named instead "Keep all packages in its current state" or "Reset state
>> of all packages".
>>
>>
>> If you want to go back to the state before confirming the upgrade
>> intentions, you have to mark the packages to be upgraded as "keep".
>>
> Thank you for the explanation, and it's acceptable for me.
> So this bug can be closed.

I think that it's better to leave it open for a while in the case that
people find the same problem.

Thanks for the feedback.


Cheers.
--
Manuel A. Fernandez Montecelo 




Hello, Manuel,

I cannot cancel pending actions which were scheduled by parsing the 
output from debsecan in this way:


# debsecan --only-fixed --suite sid|fgrep urgency |fgrep -v low|awk 
'{print $2}'|sort -u|xargs aptitude --schedule-only install


This behaviour might be related to the bug in question, and I find it 
inconvenient. Do we still have any opportunity of one-touch cancelling 
some scheduled actions in aptitude?


Best regards
Andrei Demekhov

___
Aptitude-devel mailing list
Aptitude-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel