Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #245327 > unrolled thread

Re: Uninstalling a package removes other essential packages: What is the best course of action?

Back to article view | Back to linux.debian.user

Contents

  Re: Uninstalling a package removes other essential packages: What is  the best course of action? "Andrew M.A. Cater" <amacater@einval.com> - 2022-02-13 14:20 +0100
    Re: Uninstalling a package removes other essential packages: What  is the best course of action? Stella Ashburne <rewefie@gmx.com> - 2022-02-14 11:30 +0100
      Re: Uninstalling a package removes other essential packages: What  is the best course of action? The Wanderer <wanderer@fastmail.fm> - 2022-02-14 13:50 +0100
        Re: Uninstalling a package removes other essential packages: What  is the best course of action? Stella Ashburne <rewefie@gmx.com> - 2022-02-15 19:00 +0100
          Re: Uninstalling a package removes other essential packages: What  is the best course of action? Kushal Kumaran <kushal@locationd.net> - 2022-02-15 20:00 +0100
          Re: Uninstalling a package removes other essential packages: What is the best course of action? Stefan Monnier <monnier@iro.umontreal.ca> - 2022-02-15 20:30 +0100
          Re: Uninstalling a package removes other essential packages: What  is the best course of action? The Wanderer <wanderer@fastmail.fm> - 2022-02-16 03:10 +0100
            Re: Uninstalling a package removes other essential packages: What  is the best course of action? Stella Ashburne <rewefie@gmx.com> - 2022-02-16 14:40 +0100
              Re: Uninstalling a package removes other essential packages: What  is the best course of action? The Wanderer <wanderer@fastmail.fm> - 2022-02-16 14:50 +0100
                Re: Uninstalling a package removes other essential packages: What  is the best course of action? Stella Ashburne <rewefie@gmx.com> - 2022-02-17 07:10 +0100
              Re: Uninstalling a package removes other essential packages: What is  the best course of action? <tomas@tuxteam.de> - 2022-02-16 15:10 +0100
                Re: Uninstalling a package removes other essential packages: What  is the best course of action? Curt <curty@free.fr> - 2022-02-16 16:40 +0100
                  Re: Uninstalling a package removes other essential packages: What is  the best course of action? David Wright <deblis@lionunicorn.co.uk> - 2022-02-16 21:40 +0100
                    Re: Uninstalling a package removes other essential packages: What is  the best course of action? <tomas@tuxteam.de> - 2022-02-17 06:50 +0100
                      Re: Uninstalling a package removes other essential packages: What  is the best course of action? Curt <curty@free.fr> - 2022-02-17 10:50 +0100
                        Re: Uninstalling a package removes other essential packages: What is  the best course of action? <tomas@tuxteam.de> - 2022-02-17 11:00 +0100
                    Re: Uninstalling a package removes other essential packages: What  is the best course of action? Curt <curty@free.fr> - 2022-02-17 10:50 +0100
                      Re: Uninstalling a package removes other essential packages: What is  the best course of action? <tomas@tuxteam.de> - 2022-02-17 11:00 +0100
                Re: Uninstalling a package removes other essential packages: What  is the best course of action? Stella Ashburne <rewefie@gmx.com> - 2022-02-17 07:10 +0100
                  Re: Uninstalling a package removes other essential packages: What is  the best course of action? <tomas@tuxteam.de> - 2022-02-17 09:30 +0100
      Re: Uninstalling a package removes other essential packages: What is  the best course of action? Jonathan Dowland <jon+debian-user@dow.land> - 2022-02-17 11:10 +0100
        Re: Uninstalling a package removes other essential packages: What  is the best course of action? Tixy <tixy@yxit.co.uk> - 2022-02-17 18:10 +0100

Page 1 of 2  [1] 2  Next page →

#245327 — Re: Uninstalling a package removes other essential packages: What is the best course of action?

Stella (and others)

This is apparently a long standing bug from pango1.0 

Debian bug #565500

and has been outstanding for a decade or so. Thai poses interesting font,
formatting and display properties - if you're not Thai, it doesn't matter
to you, but, as you can see it's fairly well embedded into various
libraries.

It's about as relevant to you as the fact that the Debian installer supports
several languages: if you don't use them in install and set up the locales
they're essentially irrelevant but are there for the convenience of people
who need them.

Hope this helps.

With every good wish, as ever,

Andy Cater

[toc] | [next] | [standalone]

#245364 — Re: Uninstalling a package removes other essential packages: What is the best course of action?

Hi Andy

> Sent: Sunday, February 13, 2022 at 9:14 PM
> From: "Andrew M.A. Cater" <amacater@einval.com>
> To: debian-user@lists.debian.org
> Subject: Re: Uninstalling a package removes other essential packages: What is the best course of action?
>
> Stella (and others)
>
> This is apparently a long standing bug from pango1.0
>
> Debian bug #565500
>
> and has been outstanding for a decade or so.

And why has the decade-old bug not been resolved, may I ask? Won't it pose a security risk such as in escalation of root privileges?

> Thai poses interesting font,
> formatting and display properties - if you're not Thai, it doesn't matter
> to you, but, as you can see it's fairly well embedded into various
> libraries.

I wonder who embed Thai fonts and code in the first place..

> It's about as relevant to you as the fact that the Debian installer supports
> several languages: if you don't use them in install and set up the locales
> they're essentially irrelevant but are there for the convenience of people
> who need them.

Indeed, I don't use non-English language versions during install and/or set up Thai-specific locales but libthai still ends up in my installed system.

My concern is whether libthai poses a security risk to Debian users.

Best regards.

Stella

[toc] | [prev] | [next] | [standalone]

#245368 — Re: Uninstalling a package removes other essential packages: What is the best course of action?

[Multipart message — attachments visible in raw view] — view raw

On 2022-02-14 at 05:28, Stella Ashburne wrote:

> Hi Andy
> 
>> From: "Andrew M.A. Cater" <amacater@einval.com>
>> 
>> Stella (and others)
>> 
>> This is apparently a long standing bug from pango1.0
>> 
>> Debian bug #565500
>> 
>> and has been outstanding for a decade or so.
> 
> And why has the decade-old bug not been resolved, may I ask?

I have only a vague guess about this, based on reading the bug report
and the other bug reports (not all on the Debian bug tracker) linked
from it. Your guess on that front may well be as good as mine; have you
read those bug reports?

> Won't it pose a security risk such as in escalation of root
> privileges?

Only if libthai itself contains a security vulnerability which would
make such escalation possible - in which case it would be more important
and more appropriate to fix that bug than to fix this one.

>> Thai poses interesting font, formatting and display properties - if
>> you're not Thai, it doesn't matter to you, but, as you can see it's
>> fairly well embedded into various libraries.
> 
> I wonder who embed Thai fonts and code in the first place..

I think you're reading this wrong.

If you look at the package description for libpango-1.0-0 (which, as
pointed out elsewhere, depends on libthai0 and is the reason why
libthai0 is installed on your system), you'll see that it says in part:

>>> Pango is a library for layout and rendering of text, with an 
>>> emphasis on internationalization. Pango can be used anywhere
>>> that text layout is needed.

It includes layout-and-rendering support for many, many languages. What
this means in practice is that it implements a set of functions which
other programs can call when they want to delegate the task of laying
out and rendering text.

The benefit of using those functions when writing a program, rather than
handling the work yourself, is that A: you have less work to do, and B:
you can automatically get layout and rendering right for every language
the library supports, rather than having to worry about implementing
every single one of them yourself.

Most of the languages supported by Pango do not depend on
language-specific external libraries; the code to support them is either
internal to Pango, or contained in non-language-specific internal
libraries. The Thai language (and apparently also related languages,
such as Lao) is an exception, because the rules for laying it out and
rendering it are both sufficiently complex and sufficiently distinct
from those needed by most other languages that it was deemed better to
implement that logic as a separate library.

Any program that wants to let its text be translated into languages
which use layout, etc., rules that differ from the language in which
that text was written is likely to use libpango.

Because libpango provides this type of support for Thai by depending on
an external library, installing any of those programs will result in
installing not only libpango-1.0-0, but also libthai0.

None of those programs have embedded Thai fonts, or "Thai code"
(whatever one might intend that to mean) - at least not by this avenue,
and probably not at all. Rather, they have simply delegated layout and
rendering work to libpango, by calling appropriate functions (which will
cause the program to break if libpango is not available).

libpango has also not embedded either of those things. Rather, it has
delegated the task of laying out and rendering Thai-language text to
libthai, by calling appropriate functions (which will cause the library,
and the programs calling it, to break if libthai is not available).

If a program on your system is configured to display Thai text - for
example, if you go to a Website which contains text written in that
language, such as https://en.wikipedia.org/wiki/Thai_language, and
your browser is configured to display that Website as intended - then
very probably the program will call the functions in libpango, which
will recognize the Thai language and call the functions in libthai,
which will do the layout-and-rendering work, and return the result up
the stack, so that the program will be able to display the text correctly.

If no program on your system ever encounters Thai text in a way that
makes it want to call those functions, then the code in libthai will
never actually run on your system. (And therefore your system will not
be at risk from any security vulnerabilities contained in that code.)

Please note that the only way that Thai is special here is that its
support is provided by a language-specific external library. Pango
contains comparable support for many, many other languages, they're just
all implemented internally or using non-language-specific external
libraries.

Given that the intent of libpango is to provide support for layout and
rendering of all of these languages, the alternative to having it depend
on libthai0 would not be to omit the code which supports these things;
rather, it would be to include that code in libpango-1.0-0 itself
directly, where you'd never have noticed that it was present.

>> It's about as relevant to you as the fact that the Debian installer
>> supports several languages: if you don't use them in install and
>> set up the locales they're essentially irrelevant but are there for
>> the convenience of people who need them.
> 
> Indeed, I don't use non-English language versions during install
> and/or set up Thai-specific locales but libthai still ends up in my
> installed system.

And you also don't use any of the other non-English languages for which
layout is supported by libpango (unless you happen to go to a Website
which has text in that language), but that also gets installed on your
system, so that the functions which programs use to delegate the
layout-and-rendering tasks are going to be available.

> My concern is whether libthai poses a security risk to Debian users.

Do you have any reason to believe that it might? As compared to any
other random library that Debian provides.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#245431 — Re: Uninstalling a package removes other essential packages: What is the best course of action?

Hello The Wanderer

> Sent: Monday, February 14, 2022 at 8:48 PM
> From: "The Wanderer" <wanderer@fastmail.fm>
> To: debian-user@lists.debian.org
> Subject: Re: Uninstalling a package removes other essential packages: What is the best course of action?
>
>
> Do you have any reason to believe that it might? As compared to any
> other random library that Debian provides.
>
No, I don't have the technical knowledge to audit libthai. My point is that why pull in non-English dependencies for an English-language installation....Doing so may increase the chance of attacks by hackers.

The argument that an app, library or distro is open source does not really mitigate the risks of attacks.

Consider the below decade-old bugs that had been "hiding" in plain sight:

CVE-2016-5195 (Dirty COW)
CVE-2014-0160 (Heartbleed)
CVE-2016-8655
CVE-2017-6074
CVE-2021-3156 (Baron_Samedit)

Best regards.

Stella

[toc] | [prev] | [next] | [standalone]

#245438 — Re: Uninstalling a package removes other essential packages: What is the best course of action?

On Tue, Feb 15 2022 at 06:56:28 PM, Stella Ashburne <rewefie@gmx.com> wrote:
> Hello The Wanderer
>
>> Sent: Monday, February 14, 2022 at 8:48 PM
>> From: "The Wanderer" <wanderer@fastmail.fm>
>> To: debian-user@lists.debian.org
>> Subject: Re: Uninstalling a package removes other essential
>> packages: What is the best course of action?
>>
>>
>> Do you have any reason to believe that it might? As compared to any
>> other random library that Debian provides.
>>
> No, I don't have the technical knowledge to audit libthai. My point is
> that why pull in non-English dependencies for an English-language
> installation....Doing so may increase the chance of attacks by
> hackers.
>
> The argument that an app, library or distro is open source does not
> really mitigate the risks of attacks.
>
> Consider the below decade-old bugs that had been "hiding" in plain sight:
>
> CVE-2016-5195 (Dirty COW)
> CVE-2014-0160 (Heartbleed)
> CVE-2016-8655
> CVE-2017-6074
> CVE-2021-3156 (Baron_Samedit)
>

You'll have to make your case in a bug report on the relevant package
(pango?).  The usual debian position is to enable as many options as
possible, so that the same binary package will work for a wide variety
of users.

If this does not suit your security posture, you'll need to do one or
more of the following:

- take your concerns to the upstream developers (they might need more
  concrete reasons than what you have so far)

- build the packages yourself with the offending features disabled

- uninstall the packages and manage without the additional packages that
  get removed

- isolate the packages you have issues with (and everything that depends
  on them) in separate virtual machines or other isolation mechanisms
  that satisfy your security requirements

- pay someone to audit the codebase so your security needs are met (but
  first check with upstream if they will be willing to act on issues
  discovered during audit; if not you'll need other arrangements).
  Perhaps you could offer to run one or more of the automated tools that
  can help with finding security issues (there are various open-source
  and proprietary tools in this area)

-- 
regards,
kushal

[toc] | [prev] | [next] | [standalone]

#245441 — Re: Uninstalling a package removes other essential packages: What is the best course of action?

> No, I don't have the technical knowledge to audit libthai. My point is that
> why pull in non-English dependencies for an English-language
> installation....Doing so may increase the chance of attacks by hackers.

It's pretty hard to know what might be needed and what not.
Even monolingual computer users may very well want to see characters
written in non-latin scripts on their screen.  Whether it's math
symbols, emojis, or names of coworkers of Thai origins.

It's also hard to write the code in such a way that you can have support
for Thai scripts and latin scripts but not other scripts.

And of course, the same issue holds for completely different aspects
such as support for hardware devices you'll never use, or support for
file formats you'll never use, or support for specific features of your
programs which you'll never use.

If we could generate an installation image of Debian special-custom-made
to only support the functionality that you will use, and really remove
all the code and data that can be removed without affecting your
experience, I suspect that image would be *significantly* smaller.
And arguably more secure as well, as you point out.

But it's damn hard to do it automatically.  And before we can start
doing it, we'd need to know the future (which functionality will you
use).  So instead, we have to satisfy ourselves with the very crude
approximation offered by Debian's choice of packages to install :-(

Some distributions offer a bit more control, BTW.  I'm thinking of
distributions like OpenWRT, or Gentoo.  But what they offer is still
very crude compared to what could be done in theory, with unlimited
programmer-resources.


        Stefan

[toc] | [prev] | [next] | [standalone]

#245451 — Re: Uninstalling a package removes other essential packages: What is the best course of action?

[Multipart message — attachments visible in raw view] — view raw

On 2022-02-15 at 12:56, Stella Ashburne wrote:

> Hello The Wanderer

>> Do you have any reason to believe that it might? As compared to any
>> other random library that Debian provides.
> 
> No, I don't have the technical knowledge to audit libthai. My point 
> is that why pull in non-English dependencies for an English-language 
> installation....

Because just because the main OS is configured to be in English, doesn't
mean there won't be a time when the user needs to read a document
written in that non-English language.

What if someone sends you a document that has one or more words written
in Thai? In order to be able to display that document correctly, the
computer will need code that knows how to handle the Thai language.
Whether that code is in libthai, or in a more general library, or
embedded directly in whatever program it is that's reading the document,
it's still there.

Even if you can be sure you'll never have any reason to want to read a
document that contains Thai, the same thing applies for every other
language that doesn't just use the same character set, etc., as English.
Most of them don't have sufficiently unusual and/or complex rules that
they need a dedicated library to handle them, as Thai apparently does,
but they do need something to handle whatever rules there may be.

> Doing so may increase the chance of attacks by hackers.

Not any more than pulling in any other dependency does.

> The argument that an app, library or distro is open source does not 
> really mitigate the risks of attacks.

I hadn't made that argument, I don't think, so this seems like a non
sequitur.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#245462 — Re: Uninstalling a package removes other essential packages: What is the best course of action?

Hello

> Sent: Wednesday, February 16, 2022 at 10:04 AM
> From: "The Wanderer" <wanderer@fastmail.fm>
> To: debian-user@lists.debian.org
> Subject: Re: Uninstalling a package removes other essential packages: What is the best course of action?
>
> What if someone sends you a document that has one or more words written
> in Thai? In order to be able to display that document correctly, the
> computer will need code that knows how to handle the Thai language.
> Whether that code is in libthai, or in a more general library, or
> embedded directly in whatever program it is that's reading the document,
> it's still there.
>
> Even if you can be sure you'll never have any reason to want to read a
> document that contains Thai, the same thing applies for every other
> language that doesn't just use the same character set, etc., as English.
> Most of them don't have sufficiently unusual and/or complex rules that
> they need a dedicated library to handle them, as Thai apparently does,
> but they do need something to handle whatever rules there may be.
>
So why not create libraries for Burmese, Laotian and Cambodian (Khmer) languages? Why don't we have libburmese, liblaotian and libkhmer and make them essential dependencies for libpango?

Best regards.

Stella

[toc] | [prev] | [next] | [standalone]

#245463 — Re: Uninstalling a package removes other essential packages: What is the best course of action?

[Multipart message — attachments visible in raw view] — view raw

On 2022-02-16 at 08:31, Stella Ashburne wrote:

> Hello

>> What if someone sends you a document that has one or more words
>> written in Thai? In order to be able to display that document
>> correctly, the computer will need code that knows how to handle the
>> Thai language. Whether that code is in libthai, or in a more
>> general library, or embedded directly in whatever program it is
>> that's reading the document, it's still there.
>> 
>> Even if you can be sure you'll never have any reason to want to
>> read a document that contains Thai, the same thing applies for
>> every other language that doesn't just use the same character set,
>> etc., as English. Most of them don't have sufficiently unusual
>> and/or complex rules that they need a dedicated library to handle
>> them, as Thai apparently does, but they do need something to handle
>> whatever rules there may be.
> 
> So why not create libraries for Burmese, Laotian and Cambodian
> (Khmer) languages? Why don't we have libburmese, liblaotian and
> libkhmer and make them essential dependencies for libpango?

There are a few possible answers.

A: Because the rules for handling those languages are similar enough to
those used for other languages that they can be handled by the
non-language-specific code already built in to libpango, but the rules
for handling Thai are not.

B: Because the rules for handling those languages are similar enough to
those used for Thai that they can be handled by the code already present
in libthai, so there's no need for another library.

C: Because the people who wrote the language-specific code to handle
those languages decided to write it as part of libpango, rather than as
an external library which libpango can depend on.

I don't know which of those answers is accurate, and I can't rule out
that other answers may be possible as well, but those are the
possibilities that come quickly to mind.

It may be instructive to note that the listed maintainer of libthai0 is
also the person who filed bug 620001, against libpango, about a
rendering issue that affects (affected?) both Lao and Thai. This leaves
me thinking that option B is probably less likely than the others, but I
don't know that for certain.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#245490 — Re: Uninstalling a package removes other essential packages: What is the best course of action?

Dearie

> Sent: Wednesday, February 16, 2022 at 9:45 PM
> From: "The Wanderer" <wanderer@fastmail.fm>
> To: debian-user@lists.debian.org
> Subject: Re: Uninstalling a package removes other essential packages: What is the best course of action?
>
>
> There are a few possible answers.
>
I love reading your answers and found them to be informative. And I appreciate your effort and time spent on writing them.

Best regards.

Stella

[toc] | [prev] | [next] | [standalone]

#245464

[Multipart message — attachments visible in raw view] — view raw

On Wed, Feb 16, 2022 at 02:31:21PM +0100, Stella Ashburne wrote:
> Hello

[...]

> So why not create libraries for Burmese, Laotian and Cambodian (Khmer) languages? Why don't we have libburmese, liblaotian and libkhmer and make them essential dependencies for libpango?

So why not do your research yourself?

;-)

As far as I can see [1], Thai standardisation is the farthest
along. I guess Burmese, Laotian and Cambodian are waiting for
helping hands (yours, perhaps?).

Perhaps we get a libmranmabhasa, then, who knows?

Cheers

[1] https://en.wikibooks.org/wiki/FOSS_Localization/Localization_Efforts_in_the_Asia-Pacific

-- 
t

[toc] | [prev] | [next] | [standalone]

#245472 — Re: Uninstalling a package removes other essential packages: What is the best course of action?

On 2022-02-16, <tomas@tuxteam.de> <tomas@tuxteam.de> wrote:
>
>> So why not create libraries for Burmese, Laotian and Cambodian (Khmer) la=
> nguages? Why don't we have libburmese, liblaotian and libkhmer and make the=
> m essential dependencies for libpango?
>
> So why not do your research yourself?
>
> ;-)
>

 
 Of course, it’s an excellent question. But the problem, you see, when you ask
 why something happens, how does a person answer why something happens? For
 example, Aunt Minnie is in the hospital. Why? Because she went out, slipped on
 the ice, and broke her hip. That satisfies people. It satisfies, but it
 wouldn’t satisfy someone who came from another planet and knew nothing about
 why when you break your hip do you go to the hospital. How do you get to the
 hospital when the hip is broken? Well, because her husband, seeing that her hip
 was broken, called the hospital up and sent somebody to get her. All that is
 understood by people. And when you explain a why, you have to be in some
 framework that you allow something to be true. Otherwise, you’re perpetually
 asking why.

https://fs.blog/richard-feynman-on-why-questions/

Stella!!!!!!!!!!!

[toc] | [prev] | [next] | [standalone]

#245484

On Wed 16 Feb 2022 at 15:38:22 (-0000), Curt wrote:
> On 2022-02-16, <tomas@tuxteam.de> <tomas@tuxteam.de> wrote:
> >
> >> So why not create libraries for Burmese, Laotian and Cambodian (Khmer) la=
> > nguages? Why don't we have libburmese, liblaotian and libkhmer and make the=
> > m essential dependencies for libpango?
> >
> > So why not do your research yourself?
> >
> > ;-)
>  
>  Of course, it’s an excellent question. But the problem, you see, when you ask
>  why something happens, how does a person answer why something happens? For
>  example, Aunt Minnie is in the hospital. Why? Because she went out, slipped on
>  the ice, and broke her hip. That satisfies people. It satisfies, but it
>  wouldn’t satisfy someone who came from another planet and knew nothing about
>  why when you break your hip do you go to the hospital. How do you get to the
>  hospital when the hip is broken? Well, because her husband, seeing that her hip
>  was broken, called the hospital up and sent somebody to get her. All that is
>  understood by people. And when you explain a why, you have to be in some
>  framework that you allow something to be true. Otherwise, you’re perpetually
>  asking why.
> 
> https://fs.blog/richard-feynman-on-why-questions/

Tomas's question seems to me more rhetorical than a scientific inquiry.
Great video, though. Thanks.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#245489

[Multipart message — attachments visible in raw view] — view raw

On Wed, Feb 16, 2022 at 02:37:02PM -0600, David Wright wrote:
> On Wed 16 Feb 2022 at 15:38:22 (-0000), Curt wrote:
> > On 2022-02-16, <tomas@tuxteam.de> <tomas@tuxteam.de> wrote:

[...]

> > > So why not do your research yourself?
> > >
> > > ;-)
> >  
> >  Of course, it’s an excellent question [...]

> > https://fs.blog/richard-feynman-on-why-questions/
> 
> Tomas's question seems to me more rhetorical than a scientific inquiry.

In a way, yes. I was trying my best to animate people to look into stuff.
The answer is, nevertheless, a good read.

> Great video, though. Thanks.

Absolutely.

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#245498 — Re: Uninstalling a package removes other essential packages: What is the best course of action?

On 2022-02-17, <tomas@tuxteam.de> <tomas@tuxteam.de> wrote:
>
> --Isw399PmXxwTK8QE
> Content-Type: text/plain; charset=utf-8
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Wed, Feb 16, 2022 at 02:37:02PM -0600, David Wright wrote:
>> On Wed 16 Feb 2022 at 15:38:22 (-0000), Curt wrote:
>> > On 2022-02-16, <tomas@tuxteam.de> <tomas@tuxteam.de> wrote:
>
> [...]
>
>> > > So why not do your research yourself?
>> > >
>> > > ;-)
>> > =20
>> >  Of course, it=E2=80=99s an excellent question [...]
>
>> > https://fs.blog/richard-feynman-on-why-questions/
>>=20
>> Tomas's question seems to me more rhetorical than a scientific inquiry.
>
> In a way, yes. I was trying my best to animate people to look into stuff.
> The answer is, nevertheless, a good read.

Yeah, I really meant to refer to Stella, sorry.

>> Great video, though. Thanks.
>
> Absolutely.
>
> Cheers
> --=20
> t
>
> --Isw399PmXxwTK8QE
> Content-Type: application/pgp-signature; name="signature.asc"
>
>
> --Isw399PmXxwTK8QE--
>
>


-- 

[toc] | [prev] | [next] | [standalone]

#245500

[Multipart message — attachments visible in raw view] — view raw

On Thu, Feb 17, 2022 at 09:41:30AM -0000, Curt wrote:
> On 2022-02-17, <tomas@tuxteam.de> <tomas@tuxteam.de> wrote:

[...]

> > On Wed, Feb 16, 2022 at 02:37:02PM -0600, David Wright wrote:

[...]

> >> Tomas's question seems to me more rhetorical than a scientific inquiry.
> >
> > In a way, yes. I was trying my best to animate people to look into stuff.
> > The answer is, nevertheless, a good read.
> 
> Yeah, I really meant to refer to Stella, sorry.

No need. I enjoyed the exchange. All of it.

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#245497 — Re: Uninstalling a package removes other essential packages: What is the best course of action?

On 2022-02-16, David Wright <deblis@lionunicorn.co.uk> wrote:
> On Wed 16 Feb 2022 at 15:38:22 (-0000), Curt wrote:
>> On 2022-02-16, <tomas@tuxteam.de> <tomas@tuxteam.de> wrote:
>> >
>> >> So why not create libraries for Burmese, Laotian and Cambodian (Khmer) la=
>> > nguages? Why don't we have libburmese, liblaotian and libkhmer and make the=
>> > m essential dependencies for libpango?
>> >
>> > So why not do your research yourself?
>> >
>> > ;-)
>>  
>>  Of course, it’s an excellent question. But the problem, you see, when you ask
>>  why something happens, how does a person answer why something happens? For
>>  example, Aunt Minnie is in the hospital. Why? Because she went out, slipped on
>>  the ice, and broke her hip. That satisfies people. It satisfies, but it
>>  wouldn’t satisfy someone who came from another planet and knew nothing about
>>  why when you break your hip do you go to the hospital. How do you get to the
>>  hospital when the hip is broken? Well, because her husband, seeing that her hip
>>  was broken, called the hospital up and sent somebody to get her. All that is
>>  understood by people. And when you explain a why, you have to be in some
>>  framework that you allow something to be true. Otherwise, you’re perpetually
>>  asking why.
>> 
>> https://fs.blog/richard-feynman-on-why-questions/
>
> Tomas's question seems to me more rhetorical than a scientific inquiry.
> Great video, though. Thanks.

Actually, I wanted to allude to Stella but should've obviously just
responded to one of *her* posts.

And when Feynman refers to someone from another planet I think instead
of AI, and how deep you have to go in knowledge of all sorts, in
successively deeper frameworks of truth, before you can arrive at what
we do "naturally."


> Cheers,
> David.
>
>


-- 

[toc] | [prev] | [next] | [standalone]

#245499

[Multipart message — attachments visible in raw view] — view raw

On Thu, Feb 17, 2022 at 09:40:40AM -0000, Curt wrote:
> On 2022-02-16, David Wright <deblis@lionunicorn.co.uk> wrote:

[...]

> > Tomas's question seems to me more rhetorical than a scientific inquiry.
> > Great video, though. Thanks.
> 
> Actually, I wanted to allude to Stella but should've obviously just
> responded to one of *her* posts.
> 
> And when Feynman refers to someone from another planet I think instead
> of AI, and how deep you have to go in knowledge of all sorts, in
> successively deeper frameworks of truth, before you can arrive at what
> we do "naturally."

Add to it: "it's a process, not a state", and then you've got the whole
mess :)

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#245492 — Re: Uninstalling a package removes other essential packages: What is the best course of action?

Dearie

> Sent: Wednesday, February 16, 2022 at 10:05 PM
> From: tomas@tuxteam.de
> To: debian-user@lists.debian.org
> Subject: Re: Uninstalling a package removes other essential packages: What is the best course of action?
>
>
> So why not do your research yourself?
>
Honestly I don't know where to start.

You're my daddy's contemporary and besides, I wasn't even born when Linux or Debian burst onto the scene.

> As far as I can see [1], Thai standardisation is the farthest
> along. I guess Burmese, Laotian and Cambodian are waiting for
> helping hands (yours, perhaps?).
>
I do not possess the technical skills to accomplish it.

Best regards.

Stella

[toc] | [prev] | [next] | [standalone]

#245496

[Multipart message — attachments visible in raw view] — view raw

On Thu, Feb 17, 2022 at 07:05:33AM +0100, Stella Ashburne wrote:
> Dearie
> 
> > Sent: Wednesday, February 16, 2022 at 10:05 PM
> > From: tomas@tuxteam.de
> > To: debian-user@lists.debian.org
> > Subject: Re: Uninstalling a package removes other essential packages: What is the best course of action?
> >
> >
> > So why not do your research yourself?
> >
> Honestly I don't know where to start.

There are, of course, many ways to go about it. And, of course, it
has the potential to eat all the time resources available, and then
some. So everyone has to choose where to cut :)

I'll present one way here, which always reminds me of the incredible
gift we have: access to most of the source code for the things we
use. For our case (libthai), start with apt. The library package is
called libthai0, so (I'm on buster; YMMV):

  tomas@trotzki:~$ apt rdepends libthai0
  libthai0
  Reverse Depends:
    Depends: libthai-dev (= 0.1.28-3)
    Depends: php-wikidiff2 (>= 0.1.25)
    Depends: libsombok3 (>= 0.1.12)
    Depends: scim-thai (>= 0.1.12)
    Suggests: libqt5core5a
    Depends: libpango-1.0-0 (>= 0.1.25)
    Depends: libm17n-0 (>= 0.1.12)
    Depends: ibus-libthai (>= 0.1.19)
    Breaks: libthai-data (<< 0.1.10)
    Depends: gtk-im-libthai (>= 0.1.12)
    Depends: gtk3-im-libthai (>= 0.1.12)

That gives you the "reverse dependencies", i.e. which packages do
depend on libthai? Many of those (roughly: those having "im" in
their name) are "input methods". Also that ibus- thing. The two
dependencies with potential to "spread" are libpango (nearly
everything rendering text these days uses that) and libqt5core5a
(if you are using Qt applications).

Let's have a look at this libpango-1.0-0:

  tomas@trotzki:~$ apt show libpango-1.0-0
  Package: libpango-1.0-0
  Version: 1.46.2-3
  Priority: optional
  Section: libs
  Source: pango1.0
  Maintainer: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
  Installed-Size: 441 kB
  Depends: fontconfig (>= 2.1.91), libc6 (>= 2.14), libfribidi0 (>= 1.0.0), libglib2.0-0 (>= 2.61.2), libharfbuzz0b (>= 2.1.1), libthai0 (>= 0.1.25)
  [...]

So the source package is pango1.0. You could install the source
package and have a look into it, but Debian offers you:

  https://sources.debian.org/

Enter "pango1.0" into that little box ("by package name"). If
you're bold, you can just stick that into the URL

  https://sources.debian.org/search/pango1.0/

You click on that one URL and there you have the sources, nicely
sorted by Debian version. Click on yours (mine is buster). You'll
notice that little box on the right labelled "search" (there's
also a dropdown: we'll ignore that). It is pre-set with
"package:pango1.0". We add to it (separated by a space) "libthai"
and click on "search".

Now it searches all of pango's sources for occurrences of libthai.

I'll leave that here. Explore. Come back with questions. And mind
those rabbit holes. Only pick the enjoyable ones :)

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web