Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#978013: libpcre2-8-0: Doesn't describe why I want/need a 8-bit runtime on my 64-bit machine
49 views
Skip to first unread message
Diederik de Haas
Dec 24, 2020, 7:10:04 AM12/24/20
to
Package: libpcre2-8-0
Version: 10.36-2
Severity: minor
On my system I have the 8/16/32 bit versions of the pcre2 library
installed.
The discription only tells me that this is the 8-bit runtime version.
But I have no idea why I/anyone would want a 8-bit runtime on my 64-bit
machine, where I'd normally expect (only) a 64-bit version, which
apparently, doesn't exist.
Can the long description field (f.e.) be expanded to explain *why* I or
anyone else would want to install the 8 bit version and not the 16 or 32
bit ones? The same goes for the 16 and 32 bit versions.
Right now, it only duplicates the info from the short description.
Cheers,
Diederik
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing'), (101, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.9.0-5-amd64 (SMP w/16 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libpcre2-8-0 depends on:
ii libc6 2.31-6
libpcre2-8-0 recommends no packages.
libpcre2-8-0 suggests no packages.
-- no debconf information
Version: 10.36-2
Severity: minor
On my system I have the 8/16/32 bit versions of the pcre2 library
installed.
The discription only tells me that this is the 8-bit runtime version.
But I have no idea why I/anyone would want a 8-bit runtime on my 64-bit
machine, where I'd normally expect (only) a 64-bit version, which
apparently, doesn't exist.
Can the long description field (f.e.) be expanded to explain *why* I or
anyone else would want to install the 8 bit version and not the 16 or 32
bit ones? The same goes for the 16 and 32 bit versions.
Right now, it only duplicates the info from the short description.
Cheers,
Diederik
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing'), (101, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.9.0-5-amd64 (SMP w/16 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libpcre2-8-0 depends on:
ii libc6 2.31-6
libpcre2-8-0 recommends no packages.
libpcre2-8-0 suggests no packages.
-- no debconf information
Matthew Vernon
Nov 7, 2021, 7:40:03 AM11/7/21
to
Hi,
On 24/12/2020 11:56, Diederik de Haas wrote:
> On my system I have the 8/16/32 bit versions of the pcre2 library
> installed.
> The discription only tells me that this is the 8-bit runtime version.
> But I have no idea why I/anyone would want a 8-bit runtime on my 64-bit
> machine, where I'd normally expect (only) a 64-bit version, which
> apparently, doesn't exist.
The short answer is because you installed something that depends on the
8-bit runtime version.
The slightly longer answer is that the X-bit naming refers to the size
of code points - so the 8-bit version takes strings composed of chars,
representing single-byte characters, or UTF-8 strings. The 16 and 32
libraries instead take strings contained in arrays of 16 or 32-bit code
units (which again might be single-unit characters or UTF-16 or UTF-32
strings.
Regards,
Matthew
On 24/12/2020 11:56, Diederik de Haas wrote:
> On my system I have the 8/16/32 bit versions of the pcre2 library
> installed.
> The discription only tells me that this is the 8-bit runtime version.
> But I have no idea why I/anyone would want a 8-bit runtime on my 64-bit
> machine, where I'd normally expect (only) a 64-bit version, which
> apparently, doesn't exist.
8-bit runtime version.
The slightly longer answer is that the X-bit naming refers to the size
of code points - so the 8-bit version takes strings composed of chars,
representing single-byte characters, or UTF-8 strings. The 16 and 32
libraries instead take strings contained in arrays of 16 or 32-bit code
units (which again might be single-unit characters or UTF-16 or UTF-32
strings.
Regards,
Matthew
Diederik de Haas
Nov 7, 2021, 11:00:03 AM11/7/21
to
Hi,
On Sunday, 7 November 2021 13:08:38 CET Matthew Vernon wrote:
> On 24/12/2020 11:56, Diederik de Haas wrote:
> > On my system I have the 8/16/32 bit versions of the pcre2 library
> > installed.
> > The discription only tells me that this is the 8-bit runtime version.
> > But I have no idea why I/anyone would want a 8-bit runtime on my 64-bit
> > machine, where I'd normally expect (only) a 64-bit version, which
> > apparently, doesn't exist.
>
> The short answer is because you installed something that depends on the
> 8-bit runtime version.
I actually knew that, but I should've phrased my request a bit clearer.
$ aptitude why libpcre2-8-0
i git Depends libpcre2-8-0 (>= 10.34)
Let's take the Linux kernel as an example, which ofc uses git and has
contributors from all over the world, include those of whose name won't always
fit in ANSI/UTF-8 chars. Let's take Japanese as an example.
So if I want to query git's log (assuming it uses RE for that) for commits by
a Japanese person, it won't be able to find it because it's using the 8-bit
variant of libpcre2?
> The slightly longer answer is that the X-bit naming refers to the size
> of code points - so the 8-bit version takes strings composed of chars,
> representing single-byte characters, or UTF-8 strings. The 16 and 32
> libraries instead take strings contained in arrays of 16 or 32-bit code
> units (which again might be single-unit characters or UTF-16 or UTF-32
> strings.
My suspicion is that the choice for either the 8, 16 or 32 bit version isn't
made as consciously as possibly should. Until your reply I wouldn't have known
which one to pick if I wanted to package a program and would likely just copy
what someone else has done (which may have followed the same 'procedure').
But if this information is added to the long description (+possible trade-
offs*), then people can make a better informed and thereby a (more) deliberate
choice.
*) I don't know, but I can imagine that the 8bit version is faster then the
16bit one. The downside is that you'll exclude RE using UTF-16/32 chars, like
Japanese above. Depending on the use case, that can be acceptable. Or not.
Cheers,
Diederik
On Sunday, 7 November 2021 13:08:38 CET Matthew Vernon wrote:
> On 24/12/2020 11:56, Diederik de Haas wrote:
> > On my system I have the 8/16/32 bit versions of the pcre2 library
> > installed.
> > The discription only tells me that this is the 8-bit runtime version.
> > But I have no idea why I/anyone would want a 8-bit runtime on my 64-bit
> > machine, where I'd normally expect (only) a 64-bit version, which
> > apparently, doesn't exist.
>
> The short answer is because you installed something that depends on the
> 8-bit runtime version.
$ aptitude why libpcre2-8-0
i git Depends libpcre2-8-0 (>= 10.34)
Let's take the Linux kernel as an example, which ofc uses git and has
contributors from all over the world, include those of whose name won't always
fit in ANSI/UTF-8 chars. Let's take Japanese as an example.
So if I want to query git's log (assuming it uses RE for that) for commits by
a Japanese person, it won't be able to find it because it's using the 8-bit
variant of libpcre2?
> The slightly longer answer is that the X-bit naming refers to the size
> of code points - so the 8-bit version takes strings composed of chars,
> representing single-byte characters, or UTF-8 strings. The 16 and 32
> libraries instead take strings contained in arrays of 16 or 32-bit code
> units (which again might be single-unit characters or UTF-16 or UTF-32
> strings.
made as consciously as possibly should. Until your reply I wouldn't have known
which one to pick if I wanted to package a program and would likely just copy
what someone else has done (which may have followed the same 'procedure').
But if this information is added to the long description (+possible trade-
offs*), then people can make a better informed and thereby a (more) deliberate
choice.
*) I don't know, but I can imagine that the 8bit version is faster then the
16bit one. The downside is that you'll exclude RE using UTF-16/32 chars, like
Japanese above. Depending on the use case, that can be acceptable. Or not.
Cheers,
Diederik
Matthew Vernon
Nov 7, 2021, 12:50:03 PM11/7/21
to
Hi,
On 07/11/2021 15:52, Diederik de Haas wrote:
> On Sunday, 7 November 2021 13:08:38 CET Matthew Vernon wrote:
>> On 24/12/2020 11:56, Diederik de Haas wrote:
>> The short answer is because you installed something that depends on the
>> 8-bit runtime version.
>
> I actually knew that, but I should've phrased my request a bit clearer.
>
> $ aptitude why libpcre2-8-0
> i git Depends libpcre2-8-0 (>= 10.34)
>
> Let's take the Linux kernel as an example, which ofc uses git and has
> contributors from all over the world, include those of whose name won't always
> fit in ANSI/UTF-8 chars. Let's take Japanese as an example.
UTF-8 can represent all valid Unicode code points (cf
https://en.wikipedia.org/wiki/UTF-8 ). So I think your argument is
incorrect.
Regards,
Matthew
On 07/11/2021 15:52, Diederik de Haas wrote:
> On Sunday, 7 November 2021 13:08:38 CET Matthew Vernon wrote:
>> On 24/12/2020 11:56, Diederik de Haas wrote:
>> The short answer is because you installed something that depends on the
>> 8-bit runtime version.
>
> I actually knew that, but I should've phrased my request a bit clearer.
>
> $ aptitude why libpcre2-8-0
> i git Depends libpcre2-8-0 (>= 10.34)
>
> Let's take the Linux kernel as an example, which ofc uses git and has
> contributors from all over the world, include those of whose name won't always
> fit in ANSI/UTF-8 chars. Let's take Japanese as an example.
https://en.wikipedia.org/wiki/UTF-8 ). So I think your argument is
incorrect.
Regards,
Matthew
0 new messages