--- Begin Message ---
Package: libapt-pkg5.0 Version: 1.2.9 Severity: important Tags: l10n
Dear Maintainer,
* What led up to the situation?
apt-get, aptitude, apt-cache, etc all report the following error
E:Invalid record in the preferences file /etc/apt/preferences.d/my.pref, no Package header
* What exactly did you do (or not do) that was effective (or
ineffective)?
Create a file in /etc/apt/preferences.d/ using an ansible template that is
UTF-8 encoded.
* What was the outcome of this action?
None of the APT front-end utilities respect the preferences (pinning) set in the new preferences file.
* What outcome did you expect instead?
Ideally, The preferences in the new preferences file should be respected and apt should be
capable of dealing with files of any file encoding or the error message returned to the
front-end utilities should indicate a problem with the file or its encoding.
— System Information: Debian Release: stretch/sid Architecture: amd64 (x86_64)
Kernel: Linux 4.3.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Versions of packages libapt-pkg5.0 depends on: ii libbz2-1.0 1.0.6-8 ii libc6 2.21-6 ii libgcc1 1:5.3.1-12 ii liblz4-1 0.0~r131-1 ii liblzma5 5.1.1alpha+20120614-2.1 ii libstdc++6 5.3.1-12 ii zlib1g 1:1.2.8.dfsg-2+b1
Versions of packages libapt-pkg5.0 recommends: ii apt 1.2
libapt-pkg5.0 suggests no packages.
— no debconf information
![]()
--- End Message ---
--- Begin Message ---
Control: tags -1 - l10n + wontfix
Control: severity -1 minor
On Sun, Apr 03, 2016 at 03:51:30PM +0200, Shalom Bhooshi wrote:
> Package: libapt-pkg5.0
> Version: 1.2.9
> Severity: important
> Tags: l10n
The 'bug' has nothing to do with localisation, so dropping the tag.
Severity dropping is explained later along with wontfix & done.
> * What led up to the situation?
>
> apt-get, aptitude, apt-cache, etc all report the following error
> E:Invalid record in the preferences file /etc/apt/preferences.d/my.pref, no Package header
In general, it would have been nice if you had attached the offending
file, so that we have a chance to reproduce this. I use UTF-8 characters
all the time (also in this mail) and can't reproduce this problem with
a "UTF-8 Unicode text" file as identified by 'file'.
> * What exactly did you do (or not do) that was effective (or
> ineffective)?
>
> Create a file in /etc/apt/preferences.d/ using an ansible template that is
> UTF-8 encoded.
I have the strong feeling that this is a file with a BOM [0] in which
case this is a minor 'bug' as you could just as well save the file
without a BOM as there is no point in having it for UTF-8 – and it
causes all sorts of problems…
[0] https://en.wikipedia.org/wiki/Byte_order_mark
(Note to self: 'set bomb' to force vim to write it – how fitting)
> * What outcome did you expect instead?
>
> Ideally, The preferences in the new preferences file should be respected and apt should be
> capable of dealing with files of any file encoding or the error message returned to the
> front-end utilities should indicate a problem with the file or its encoding.
We are not going to support UTF-16 encoding (or higher) [regardless of
its endianness] because that is hard™ and there is no point, so that
will probably remain being an error.
The UTF-8 BOM ignoring is debatable, but while it sounds easy, it is
usually hard in practice and usually not done if there isn't a strong
reason – and that is the problem: There is no strong reason here. The
list of linux tools not supporting BOM is long starting with your $SHELL
already. The error messages they show are equally useless, too (if they
show one – cat e.g. will produce invalid files [as the BOM of the second
file isn't removed]). So we are in perfectly good company.
The only tools I could find who actually support it are tools who have
to deal with files created on a Window machine… the amount of those is
going to be small for the time being as you seem to be the very first
person to report such an issue in 18 years (+ 3 days) of APT.
In the end, these files (preferences, but sources and conf are no
different) aren't general propose text files but configuration files
requiring a certain format to be interpreted correctly – and in our case
the file format doesn't allow BOMs, so instead of leaving this report
linger forever as wontfix (as I doubt anyone will ever touch it as there
are hundreds of more interesting & useful things to work on in apt)
I can go a bit further and close this bug as not-a-bug.
Best regards
David Kalnischkies
Attachment:
signature.asc
Description: PGP signature
--- End Message ---