Bug#703366: RFH: apt-file -- search for files within Debian packages (command-line interface)
On 2013-03-20 18:30, Stefan Fritsch wrote:
> On Wednesday 20 March 2013, Niels Thykier wrote:
>>> [...]
>>>
>>> I (and I guess many other users) would be pleased if we could
>>> reach a point in which "apt-get update" (or its countless
>>> alternative ways) would update indeed all data I requested to be
>>> downloaded as a user rather than remembering to run also
>>> "apt-file update" (and "debtags update" and and and).
>>>
>>>
>>
>> Indeed that would be great. Maybe packages like apt-file could
>> install a file in some directory APT reads saying "Please download
>> X with updates" ?
>
> That would be the perfect solution. Unfortunately, it would also mean
> that apt's pdiff implementation would need to be rewritten because it
> is so inefficient. [...]
I spoke with David Kalnischkies (DonKult) and he told me that (part of)
the reason why it is slow is that it makes no assumption about pdiffs.
It is my understanding (of the code) that apt-file just blindly
downloads all ("new") patches and applies them in one go.
Allegedly, rerepro can merge pdiffs so not all of them needs to be
applied and (understandably) the APT maintainers do not want that to
break. The solution is probably to extend the pdiff format (e.g. like
the suggestion in [1]), so the client side can see exactly which patches
are needed (instead of having to do them one at a time).
To this end, I have been making a bit of noise in #d-ftp; hopefully I
will have news here soon.
> But of course, if someone would tackle that problem, the benefit would
> be much greater than only to apt-file. Maybe this would be a nice GSOC
> project? Don't know if it is too late for this year's deadline,
> though.
>
David reminded me that the APT side of things already had a GSoC last
year[2]. The code has not been merged yet but at least a
proof-of-concept branch is there. Assuming that can be used, we are
probably very close to making apt-file's update/purge commands obsolete.
As understood Nick, he was not interested in maintaining the current
Perl variant of apt-file, but he would be interested in rewriting (and
maintain said rewrite of) apt-file. He was certain he could improve the
search speed of apt-file while doing so. Given the results of his
apt-show-versions rewrite I am looking forward to that rewrite with
great anticipation. :)
What I propose we do is that I take over the maintenance of the current
apt-file. I will focus on making apt-file update/purge obsolete.
Meanwhile, Nick can work on his rewrite in parallel - possibly in the
same source tree. I am okay either way and I certainly do not mind an
extra co-maintainer.
As Nick's rewrite become more feature complete, the current code could
then delegate more and more tasks to it. In a (hopefully) not too
distant future, the Perl code can then be removed. :)
~Niels
[1] https://lists.debian.org/deity/2009/08/msg00169.html
[2]
http://wiki.debian.org/SummerOfCode2012/StudentApplications/BogdanPurcareata
https://launchpad.net/apt-fetcher
Reply to: