[Aptitude-devel] Bug#832320: aptitude: -t <release> download <package> broken?

[Jörg-Volker Peetz]

Manuel A. Fernandez Montecelo wrote on 07/24/16 23:53:
> Control: tags -1 + moreinfo
> 
> 
> Hi,
> 
> 2016-07-24 09:56 Jörg-Volker Peetz:
>> Package: aptitude
>> Version: 0.8.2-1
>> Severity: normal
>>
>> Dear Maintainer(s),
>>
>> commanding
>>
>>  aptitude -t sid download mksh
>>
>> fails with the message
>>
>>  Subcommand not supported: -t
>>
>> In the previous version 0.8.1-1 the command succeeds.
>> The now no longer in the man-page documented
>>
>>  aptitude download <package>/<release>
>>
>> still works.
> 
> Thanks for the report.
> 
> Here I was wondering if anybody was using that operation at all, and
> it's the first bug received after the last release...
> 
> 
> Basically, aptitude now calls "apt download" on your behalf.  I did this
> because it seems a bit unneeded to reimplement every bit of apt
> functionality instead of reusing, and specially when reimplementing it
> badly -- in this case, aptitude was downloading without check for valid
> signatures or anything, or other sensible things that apt probably does.

Yes, this makes sense. And from the man-page I see that apt-get knows "-t
<release>" as well as "<name>/<release>".
I thought the problem I reported was just a bug in the handover to apt-get. But
I didn't take a look into the source code.

I mainly use aptitude in CLI mode an value especially the search pattern
abilities. Maybe apt-get inherits this functionality sometimes in the future ;-)

> 
> So I am not sure what to do in this case.  Probably we should handle
> "-t" specially since it's quite related to the download subcommand, even
> if it's only to say "use 'aptitude download package/release' instead".
> 
> 
> It will need some thinking about how to address this a bit more
> globally.
> 

As I said, apt-get does it the same way. The handover should be possible.

Thanks for your work and support.
Regards,
jvp.