Your message dated Sat, 3 Sep 2016 21:52:04 +0200
with message-id <20160903195204.konyiwy7qg6b4wvs@crossbow>
and subject line Re: [Aptitude-devel] Bug#836522: don't not show non-existent
file names
has caused the Debian Bug report #836522,
regarding don't not show non-existent file names
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
836522: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836522
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: aptitude
Version: 0.8.3-1
Severity: wishlist
Can you please not show non-existent file names,
Preparing to unpack .../09-locales_2.24-1_all.deb ...
Unpacking locales (2.24-1) over (2.24-0experimental1) ...
Preparing to unpack .../10-apt-doc_1.3~rc3_all.deb ...
Unpacking apt-doc (1.3~rc3) over (1.3~rc2) ...
Preparing to unpack .../11-bash-doc_4.4~rc2-1_all.deb ...
Instead just say
11 Preparing to unpack bash-doc_4.4~rc2-1_all.deb
or
Preparing to unpack 11 bash-doc_4.4~rc2-1_all.deb
This also avoids the user cutting and pasting non-existent file names.
--- End Message ---
--- Begin Message ---
On Sun, Sep 04, 2016 at 01:02:22AM +0800, 積丹尼 Dan Jacobson wrote:
> Can you please not show non-existent file names,
>
> Preparing to unpack .../09-locales_2.24-1_all.deb ...
> Unpacking locales (2.24-1) over (2.24-0experimental1) ...
> Preparing to unpack .../10-apt-doc_1.3~rc3_all.deb ...
> Unpacking apt-doc (1.3~rc3) over (1.3~rc2) ...
> Preparing to unpack .../11-bash-doc_4.4~rc2-1_all.deb ...
>
> Instead just say
> 11 Preparing to unpack bash-doc_4.4~rc2-1_all.deb
> or
> Preparing to unpack 11 bash-doc_4.4~rc2-1_all.deb
>
> This also avoids the user cutting and pasting non-existent file names.
The files exist at the time their name is shown, they just don't exist
anymore then you look for them – and in which place are you looking
anyway, given that nowhere is said where these files are?
Technical detail: The files are in a temporary directory created before
dpkg (which is the producer of this output) is called by libapt without
any chance of intervention from aptitude and deleted after dpkg finishes
as it should be with temprorary files. The files are in fact "only"
symlinks to the files you think they are (the ones in
/var/cache/apt/archives). The number you seem most concerned about are
a workaround for a currently unfixed bug in dpkg btw [0], which will
eventually be fixed and libapt will stop using this little number trick
then. That doesn't change the initial problem of those filenames not
being the filenames you think they are and not intended to be used the
way you try to (or used at all for that matter).
Take it as a lesson to nether blindly copy&paste stuff around!
Closing as not-a-bug for the aptitude maintainers with my libapt hat on
as it is my 'fault' and they couldn't change anything about it even if
they wanted to.
And btw: If you are "unlucky" the files in /var/cache/apt/archives they
linked to do not exist any longer after libapt finishes either depending
on what the application using it has chosen (see apts NEWS file).
Best regards
David Kalnischkies
[0]
https://anonscm.debian.org/cgit/dpkg/dpkg-tests.git/commit/?id=8ed23e4495ad5e87d08e3e784a23c517efa2b15c
signature.asc
Description: PGP signature
--- End Message ---
_______________________________________________
Aptitude-devel mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel
