[Aptitude-devel] Bug#841506: aptitude: cannot reinstall package available as update

[Jonas Smedegaard]

Quoting Manuel A. Fernandez Montecelo (2017-04-18 21:01:41)
> Hi again,
> 
> 2017-03-20 23:36 Manuel A. Fernandez Montecelo:
> >2017-03-07 23:33 GMT+01:00 Jonas Smedegaard <dr at jones.dk>:
> >> Quoting Manuel A. Fernandez Montecelo (2017-03-07 22:43:39)
> >>>
> >>> Under normal conditions, one can reinstall a single package ("l" +
> >>> "g") at any time, no problem -- it doesn't prevent to Go ahead just
> >>> because reinstall is not a supported operation.  Does this work for
> >>> you right now, I hope?
> >>
> >> It works to reinstall packages, yes.  This bug is not that reinstall
> >> stopped generally working, but that it refused to work for that specific
> >> package being in limbo, where aptitude (or dpkg bubbling through?)
> >> explicitly instructed to _reinstall_.
> >> [...]
> >>
> >>> Nevermind.  This has to do with my wrong interpretation.  When the
> >>> package to be reinstalled has been upgraded in the server, one should
> >>> upgrade, reinstall never works.
> >>
> >> I realize that your misunderstanding me quite likely stems from my bad
> >> phrasing of the subject of this bugreport: Kernel package had failed to
> >> install _moments_ before trying to reinstall - not long time befor - so
> >> situation was _not_ that the package no longer was available for
> >> re-download (I am aware that "l" does a fresh download of the current
> >> version of the package and therefore need that version to be available).
> >
> >Everything is more clear now, there are some ideas to simulate a
> >broken update and try to reproduce it.
> >
> >However I'm quite low on spare time at the moment, so it can take a while.
> 
> For the record, I could not attempt to reproduce this item properly
> (don't have space cycles to forge broken packages and check all code
> paths), but I was working with other bugs related with reinstalling and
> #851901 (incl. scheduling actions and reinstalling in later sessions)
> and never observed similar behaviour as described in a previous message:
> 
>   "Choosing "L" to reinstall and then "G", is refused with (in danish,
>   on my system) a message saying that no packages will be installed,
>   removed or upgraded, some packages could be upgraded, and I should
>   press "U" to do that."
> 
> So I am not sure what's going on, but I don't think that reinstalling is
> missing from the logic related with 'G'.
> 
> Perhaps it's related with the package half-broken state in dpkg that
> this could not proceed, or some temporary inconsistency between
> aptitude<->apt or apt<->dpkg; but indeed it does not seem to be a
> problem in the common case.

Yes, Most certainly relates to the package being half-broken in dpkg. 
Listing events, rephrased from my initial post to this bugreport:

 1) A package went into a semi-broken state needing reinstall
 2) Aptitude proxied dpkg error about 1)
 3) Attempt to use the aptitude way to reinstall fails

The bug tracked in this bugreport is 3), triggered by 1).


Yes, 1) is rare and 1) occuring while using aptitude even more rare. Not 
sure why you mention that, however.  That does not make the bug go away.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/aptitude-devel/attachments/20170418/2f8af73d/attachment.sig>