This is amazing. Yet another response that was both emailed to
me _and_ posted to USENET.

In article <vhsrvb$1oct2$4@dont-email.me>,
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>[snip]

I'm not particularly interested in the technical conent of your
article, which seems like it's trying to force a pedantic point
of interpretation without regard to the current standard (which
you admitted you didn't have a copy of) so I'm not going to
respond to that. Now you've admitted that your issue is that
someone _could_ misinterpret my statement. Ok, but this is
comp.unix.programmer, not comp.lang.c.

But I am interested in this repeated mistake of emailing and
then posting.

In another email sent to me, but curiously NOT posted to USENET,
you said that you were "trying your best" and that if your best
was not good enough, I should take steps on my end to discard
your emails. No. It's not my responsibility to deal with your
mistakes.

I find this troubling. I really don't care how long you've been
programming, whether or not APL was your third language 50 years
ago (appeal to length of experience is, of course, a logical
fallacy) or how long you used the prior version of your tool.
Three and a half years is a long time to learn your way around a
new user interface; excuses related to age and prior experience
just don't cut it. As a former Drill Instructor once told me on
Parris Island, "excuses are like assholes: everybody has one."

It's the height of arrogance to assume that your words are so
important that it's someone else's responsibility to account for
the fact that you care to post them correctly. How about,
instead of excuses and asking others to deal with your mistakes,
you take some personal responsibility for using your tools
competently? Sure, mistakes _do_ happen, but with you it seems
to happen more often than not. If you're the one continually
making the mistake, you ought to be owning that, not asking
others to take steps to deal with your failures in this regard.

Here are some ideas for you to consider:

1. If you email someone something you intended to post, why not
follow up? You could, for example, send a follow-up email
("oops, I accidentally sent that via email; sorry about that,
I'll post it instead").
2. Alternatively, you could acknowledge that in your USENET post
with a disclaimer ("this was accidentally mailed to the
respondee").
3. If you email someone when you intended to post, you could
exercise some discipline and simply not post, acknowledging
the mistake while assuming responsibility for it. Perhaps
that would encourage you to learn to use your tools
correctly.
4. If you cannot use your existing newsreader without making
this mistake so frequently, perhaps consider switching to
different software for your USENET consumption; maybe a
program that more accurately tracks your desired user
interface?
5. Perhaps make yourself a checklist of things to check before
responding; #1 on that might be, "am I sending this by email
or posting? Is that really what I want to do?"

I'm sure you can think of others.

And while you clearly have the ability to post whatever you like
to USENET, it is a choice to do so, and it sure seems you lack
the discipline and discretion to do so competently. Perhaps
consider stopping until you develop or refine the necessary
skills to do so without such frequent error.

- Dan C.

On 23.11.2024 15:24, James Kuyper wrote:
> On 11/23/24 00:09, Janis Papanagnou wrote:
>> On 23.11.2024 06:04, James Kuyper wrote:
> ...
>>> I seem to recall that I was advised that I could use an older version of
>>> Thunderbird to edit the list of buttons that are visible, something that
>>> cannot be done in the latest version. I'm afraid to go back to an older
>>> version, because so many of the updates to most of the software I own
>>> consists of security fixes. I don't want to go back to an older, less
>>> secure version of TB.
>>
>> Understandable. - But you noticed that the "Smart Reply" thing was
>> a feature of my newer Thunderbird version? - I'd think it should be
>> there, or isn't it in your version? (What version are you running?)
>
>
> 115.16.0esr

That's newer than my "newer" one. - So they changed interface again?!

Both TB versions I am using allowed some fix; none allowed it in an
obvious, acceptable form, let alone did it right in the first place.

>
> I don't have a "More/Customize Toolbar" option, only "More/Customize",
> [...]

Since you seem to be annoying someone here it's probably best to search
for a solution or workaround on the Net/Web for your TB version.

For the other (annoyed) poster I would just suggest "self-defense" in
the form of changing the email address to allow filtering. (I'm using
for Internet anyway a special spam-catch email base address, and also
added a "filter component" to that, but that's not supported by all
email systems.) - I'm sure that's not what you prefer; you'll have to
choose your path of least annoyance yourself.

Janis

On 11/20/2024 9:53 AM, Janis Papanagnou wrote:
> On 20.11.2024 12:46, Ed Morton wrote:
>>
>> Definitely. The most relevant statement about regexps is this:
>>
>>> Some people, when confronted with a problem, think "I know, I'll use
>>> regular expressions." Now they have two problems.
>
> (Worth a scribbling on a WC wall.)
>
>>
>> Obviously regexps are very useful and commonplace but if you find you
>> have to use some online site or other tools to help you write/understand
>> one or just generally need more than a couple of minutes to
>> write/understand it then it's time to back off and figure out a better
>> way to write your code for the sake of whoever has to read it 6 months
>> later (and usually for robustness too as it's hard to be sure all rainy
>> day cases are handled correctly in a lengthy and/or complicated regexp).
>
> Regexps are nothing for newbies.
>
> The inherent fine thing with Regexps is that you can incrementally
> compose them[*].[**]
>
> It seems you haven't found a sensible way to work with them?
> (And I'm really astonished about that since I know you worked with
> Regexps for years if not decades.)

I have no problem working with regexps, I just don't write lengthy or
complicated regexps, just brief, simple BREs or EREs, and I don't
restrict myself to trying to solve problems with a single regexp.

> In those cases where Regexps *are* the tool for a specific task -
> I don't expect you to use them where they are inappropriate?! -

Right, I don't, but I see many people using them for tasks that could be
done more clearly and robustly if not done with a single regexp.

> what would be the better solution[***] then?

It all depends on the problem. For example, if you need to match an
input string that must contain each of a, b, and c in any order then you
could do that in awk with this regexp or similar:

awk '/(a.*(b.*c|c.*b))|(b.*(a.*c|c.*a))|(c.*(a.*b|b.*a))/'

or you could do it with this condition comprised of regexp segments:

awk '/a/ && /b/ && /c/'

I would prefer the second solution as it's more concise and easier to
enhance (try adding "and d" to both).

As another example, someone on StackOverflow recently said they had
written the following regexp to isolate the last string before a set of
parens in a line that contains multiple such strings, some of them
nested, and they said it works in python:

^(?:^[^(]+\([^)]+\)
\(([^(]+)\([^)]+\)\))|[^(]+\(([^(]+)\([^)]+\),\s([^\(]+)\([^)]+\)\s\([^\)]+\)\)|(?:(?:.*?)\((.*?)\(.*?\)\))|(?:[^(]+\(([^)]+)\))$

I personally wouldn't consider anything remotely as lengthy or
complicated as that regexp despite their assurances that it works, I'd
use this any-awk script or similar instead:

{
rec = $0
while ( match(rec, /\([^()]*)/) ) {
tgt = substr($0,RSTART+1,RLENGTH-2)
rec = substr(rec,1,RSTART-1) RS substr(rec,RSTART+1,RLENGTH-2)
RS substr(rec,RSTART+RLENGTH)
}
gsub(/ *\([^()]*) */, "", tgt)
print tgt
}

It's a bit more code but, unlike that regexp, anyone assigned to
maintain this code in future can tell what it does with just a little
thought (and maybe adding a debugging print in the loop if they aren't
very familiar with awk), can then be sure it does what is required and
nothing else, and could easily maintain/enhance it if necessary.

Ed.

>
> Janis
>
> [*] Like the corresponding FSMs.
>
> [**] And you can also decompose them if they are merged in a huge
> expression, too large for you to grasp it. (BTW, I'm doing such
> decompositions also with other expressions in program code that
> are too bulky.)
>
> [***] Can you answer the question that another poster failed to do?
>

Dan Cross <cross@spitfire.i.gajendra.net> wrote:
> Here are some ideas for you to consider:

Sorry for replying to an old post. I do not even
remember who it is that keeps sending emails when
he intends to send follow-ups to Usenet. However,
I have a good solution.

Thunderbird is open source, maybe even free software.

I am sure it is extremely easy to either remove the
"reply" button or to bind it to the "followup" function.

Problem solved.

br,
KK

In article <vkmbsj$3kvjq$1@dont-email.me>,
Kalevi Kolttonen <kalevi@kolttonen.fi> wrote:
....
>Thunderbird is open source, maybe even free software.
>
>I am sure it is extremely easy to either remove the
>"reply" button or to bind it to the "followup" function.

I doubt it is any simple matter to find it in the massive source code, much
less to figure out how to fix it, much less figure out how to successfully
re-build (and test!) it after making your changes.

Generally, most complicated GUI software, even if technically Open Source,
is difficult, if not impossible, for ordinary people using ordinary
machines, to re-build from source. Among other things, you will generally
end up spending many hours, if not days, getting all the dependencies installed.

--
That's the Trump playbook. Every action by Trump or his supporters can
be categorized as one (or more) of:

outrageous, incompetent, or mentally ill.

gazelle@shell.xmission.com (Kenny McCormack) writes:
> Kalevi Kolttonen <kalevi@kolttonen.fi> wrote:
> ...
>>Thunderbird is open source, maybe even free software.
>>
>>I am sure it is extremely easy to either remove the
>>"reply" button or to bind it to the "followup" function.
>
> I doubt it is any simple matter to find it in the massive source code,
> much less to figure out how to fix it, much less figure out how to
> successfully re-build (and test!) it after making your changes.
>
> Generally, most complicated GUI software, even if technically Open
> Source, is difficult, if not impossible, for ordinary people using
> ordinary machines, to re-build from source. Among other things, you
> will generally end up spending many hours, if not days, getting all
> the dependencies installed.

On Debian-derived platforms, that’s what apt-get build-dep is for.
Source package rebuild is also standardized. It looks like the RH world
has something pretty similar.

So I don’t think the need to install build dependencies is likely to be
a real obstacle to rebuilding Thunderbird.

--
https://www.greenend.org.uk/rjk/

kalevi@kolttonen.fi (Kalevi Kolttonen) writes:
> Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>> Here are some ideas for you to consider:
>
> Sorry for replying to an old post. I do not even
> remember who it is that keeps sending emails when
> he intends to send follow-ups to Usenet. However,
> I have a good solution.
>
> Thunderbird is open source, maybe even free software.
>
> I am sure it is extremely easy to either remove the
> "reply" button or to bind it to the "followup" function.

Go on then?

--
https://www.greenend.org.uk/rjk/

On Fri, 27 Dec 2024 13:59:47 -0000 (UTC)
kalevi@kolttonen.fi (Kalevi Kolttonen) wrote:

> I am sure it is extremely easy to either remove the
> "reply" button or to bind it to the "followup" function.

Have you, like, actually *checked* this assertion?

In article <wwvh66p9ntv.fsf@LkoBDZeT.terraraq.uk>,
Richard Kettlewell <invalid@invalid.invalid> wrote:
....
>On Debian-derived platforms, thats what apt-get build-dep is for.
>Source package rebuild is also standardized. It looks like the RH world
>has something pretty similar.

I know all that - and, in theory, it should "just work".

But my experience is that theory and practice diverge.

Now, I may not be the most capable person in the world, probably not even
in the top 10 (or 100). But that's exactly my point. It's just not an
easy task for ordinary people under ordinary circumstances.

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/Cancer

John Ames <commodorejohn@gmail.com> writes:
>On Fri, 27 Dec 2024 13:59:47 -0000 (UTC)
>kalevi@kolttonen.fi (Kalevi Kolttonen) wrote:
>
>> I am sure it is extremely easy to either remove the
>> "reply" button or to bind it to the "followup" function.
>
>Have you, like, actually *checked* this assertion?
>

Unlikely, to be sure.

I personally still use xrn, which _is_ completely customizable
via X11 resources.

gazelle@shell.xmission.com (Kenny McCormack) writes:

> In article <wwvh66p9ntv.fsf@LkoBDZeT.terraraq.uk>,
> Richard Kettlewell <invalid@invalid.invalid> wrote:
> ...
>>On Debian-derived platforms, thats what apt-get build-dep is for.
>>Source package rebuild is also standardized. It looks like the RH world
>>has something pretty similar.
>
> I know all that - and, in theory, it should "just work".
>
> But my experience is that theory and practice diverge.
>
> Now, I may not be the most capable person in the world, probably not even
> in the top 10 (or 100). But that's exactly my point. It's just not an
> easy task for ordinary people under ordinary circumstances.

If I were not full of tasks right now, I would set up a VM with Debian
and try it out---build-dep for Thunderbird. Just to see if compiles
successfully without much hacking involved. I am also skeptical of such
things. It usually works on smaller projects; I'd be surprised and
happy to find out that it works with no hacking involved.

On Fri, 12/27/2024 11:14 AM, Kenny McCormack wrote:
> In article <wwvh66p9ntv.fsf@LkoBDZeT.terraraq.uk>,
> Richard Kettlewell <invalid@invalid.invalid> wrote:
> ...
>> On Debian-derived platforms, thats what apt-get build-dep is for.
>> Source package rebuild is also standardized. It looks like the RH world
>> has something pretty similar.
>
> I know all that - and, in theory, it should "just work".
>
> But my experience is that theory and practice diverge.
>
> Now, I may not be the most capable person in the world, probably not even
> in the top 10 (or 100). But that's exactly my point. It's just not an
> easy task for ordinary people under ordinary circumstances.
>

One of the solutions, is to not put email and USENET news, on the same tool.

I hit the reply by accident the other day here, and when I clicked
Send, a dialog whined about "Could not send because..." I have no email
account set up on the thing. Of course it cannot erroneously send
to email, because there is no email. The Reply button then is neutered.
I changed over to Followup, sent to newsgroup, and finished the job.

IDK about capable, but Thunderbird is a huge package, and the
installation may require Rust and some other materials to be
loaded. The description for building, may have started with
a Mercurial (Hg) clone, and then the build is based on that.
The tarball off the site, would be insufficient for an immediate
build. The recipe no longer describes starting with a tarball.

As a consequence, the distro people might not have a "conventional"
setup for Thunderbird. One of the distros, a .deb arrives from
Mozilla in a cardboard box. As a result of the package
being manufactured elsewhere, instead of in-house in the
Buildmeister corral, the source option just might be missing.

Still, even without doing the actual build, it would be fun
to tease the distro and see what it has to offer, and see whether
a patched source magically shows up. It would be good to know
whether in "difficult cases", it actually arrives ready to be
built for you.

For some of these "big" projects, a machine with 32GB of RAM
is recommended. Which helps with the linking phase. Some
of the compiling, the RAM footprint isn't all that large.
The procedure used to have a hideous linkage methodology
at one time, but that got modified a bit. To make a 32-bit
copy of the thing, it is best to build on a 64-bit OS!
If your distro isn't 64-bit, it would be not-possible to finish.

While a lot of distros are 64-bit only, you can *still* find 32-bit ones.
But not for much longer. Building Thunderbird on the one with
the arrow below, that could be a waste of your time. I don't know if
some PAE thing would work or not in 32-bit mode. I'm using a
mirror here, because the main site isn't as easy to get around on.

https://mirror.csclub.uwaterloo.ca/linuxmint/debian/

lmde-6-cinnamon-32bit.iso 22-Sep-2023 17:07 2G <===
lmde-6-cinnamon-64bit.iso 22-Sep-2023 16:26 3G
sha256sum.txt 01-Feb-2024 16:09 552
sha256sum.txt.gpg 01-Feb-2024 16:10 833

Paul

On Fri, 12/27/2024 10:43 AM, John Ames wrote:
> On Fri, 27 Dec 2024 13:59:47 -0000 (UTC)
> kalevi@kolttonen.fi (Kalevi Kolttonen) wrote:
>
>> I am sure it is extremely easy to either remove the
>> "reply" button or to bind it to the "followup" function.
>
> Have you, like, actually *checked* this assertion?
>

The Followup button on the copy of Thunderbird I'm typing on,
is actually a menu. It's not just a button. This is why
this nonsense happens. It's a graphical trap, a hole in the
back yard for you to fall into while walking past.

Followup V <=== Normally, you are hitting this as if it is a button
Followup
Reply All
Reply <=== If you "smear" or "wipe" the Followup V at
the top, and you're not paying attention, THAT
is when you hit the Reply.

Paul

On 2024-12-27, Kalevi Kolttonen <kalevi@kolttonen.fi> wrote:
> Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>> Here are some ideas for you to consider:
>
> Sorry for replying to an old post. I do not even
> remember who it is that keeps sending emails when
> he intends to send follow-ups to Usenet. However,
> I have a good solution.
>
> Thunderbird is open source, maybe even free software.

Thunderbird is yet another mail program whose developers think that
Usenet is just like e-mail, and can be bolted onto a mail client.

Just use a fscking newsreader.

I've never sent an e-mail by accident in slrn.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On Fri, 27 Dec 2024 15:07:59 -0300, Salvador Mirzo wrote:

> If I were not full of tasks right now, I would set up a VM with Debian
> and try it out---build-dep for Thunderbird. Just to see if compiles
> successfully without much hacking involved.

It will certainly work for (re)building the Debian package. Remember,
that’s how they build Debian in the first place.

Also, you can try a container rather than a full VM.

On Fri, 27 Dec 2024 14:56:28 +0000, Richard Kettlewell wrote:

> On Debian-derived platforms, that’s what apt-get build-dep is for.

Even if you want your build to be different from the Debian package, apt-
get build-dep will still likely get you 90% of the way to installing all
the needed dependencies.

I used this as a starting point for my Blender build. Now that is a
package with some complex dependencies.

Salvador Mirzo <smirzo@example.com> wrote:
> If I were not full of tasks right now, I would set up a VM with Debian
> and try it out---build-dep for Thunderbird. Just to see if compiles
> successfully without much hacking involved. I am also skeptical of such
> things. It usually works on smaller projects; I'd be surprised and
> happy to find out that it works with no hacking involved.

No need to be skeptical, we live in modern ages
where things have been made quite convenient for us.
Compiling Thunderbird should be very easy indeed
when we use Linux distro's package management.

I run Fedora Linux 41 xfce spin and I love it. If my
memory serves right, so far I have performed the
following steps:

1) Download the Thunderbird source RPM
dnf download --source thunderbird

2) Install the source RPM
rpm -Uvh thunderbird-128.5.2-1.fc41.src.rpm

3) Bump release from 2 to 3
vi ~/rpmbuild/SPECS/thunderbird.spec

4) Extract the tar.xz
tar xJf thunderbird-128.5.2esr.source.tar.xz

5) Edit function MsgReplyMessage to contain just "return;"

vi +/MsgReplyMessage thunderbird-128.5.2/comm/suite/mailnews/content/mailWindowOverlay.js

6) Recreate the tar.xz
tar cJf thunderbird-128.5.2esr.source.tar.xz thunderbird-128.5.2

7) Install all RPM build dependencies, letting dnf do the heavy lifting
dnf builddep ~/rpmbuild/SPECS/thunderbird.spec

8) Build Thunderbird binary RPM:

rpmbuild -bb ~/rpmbuild/SPECS/thunderbird.spec

Since Thunderbird is pretty huge, I am guessing that
the build will take some time to complete.

In Finland it is now 01:17 o'clock in the middle of the
night. Unfortunately I have to go to work tomorrow so
I must go to sleep at 2:00. I have no idea when the
build will be complete or whether my JavaScript hack
works or not.

br,
KK

Richard Kettlewell <invalid@invalid.invalid> wrote:
> kalevi@kolttonen.fi (Kalevi Kolttonen) writes:
>> Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>>> Here are some ideas for you to consider:
>>
>> Sorry for replying to an old post. I do not even
>> remember who it is that keeps sending emails when
>> he intends to send follow-ups to Usenet. However,
>> I have a good solution.
>>
>> Thunderbird is open source, maybe even free software.
>>
>> I am sure it is extremely easy to either remove the
>> "reply" button or to bind it to the "followup" function.
>
> Go on then?

Working on it.

br,
KK

On 27.12.2024 20:14, Kaz Kylheku wrote:
>> [ Thunderbird issues ]
>
> Thunderbird is yet another mail program whose developers think that
> Usenet is just like e-mail, and can be bolted onto a mail client.

I may be using Thunderbird now for two decades or more, don't recall.

That it's a combined client (for email, news, chat, and some more)
with a common [basic] GUI is not the problem. Thunderbird has a lot
of (real, unnecessary) problems that the product managers obviously
failed to understand or see. (I won't even start here to enumerate
them.) And it makes things not easier if versions differ completely
in what can be done to try to fix some of these severe shortcomings.

The state of that product is IMO beyond all hope; it would require a
complete redesign to make its interface follow some basic ergonomic
principles (including all the possible configuration capabilities).
(Mileages may vary.)

I've fixed the Reply-button issue in the two (completely different)
versions I'm mostly using - but don't ask me how I did that! - and
I'm meanwhile thus fine with Thunderbird's newsreader component in
a single mail/news application - as long as I don't follow my urge
to fix anything else in this product.

Janis

> [...]

On 28.12.2024 00:22, Kalevi Kolttonen wrote:
>> [...]
>
> No need to be skeptical, we live in modern ages
> where things have been made quite convenient for us.

LOL. :-)

> Compiling Thunderbird should be very easy indeed
> when we use Linux distro's package management.

You expect _users_ of tools to use a _development_
environment to fix *inherent* shortcomings of a tool?
(Shortcomings that should not be there in the first
place!)

> [ snip suggested 8-step development process ]

Janis

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> On 28.12.2024 00:22, Kalevi Kolttonen wrote:
>>> [...]
>>
>> No need to be skeptical, we live in modern ages
>> where things have been made quite convenient for us.
>
> LOL. :-)

My comment above was a reference to the bad old
days when you had to manually download tar.gz packages
and compile them to satisfy dependencies. Now the
builds are super easy with the help of package management.

>> Compiling Thunderbird should be very easy indeed
>> when we use Linux distro's package management.
>
> You expect _users_ of tools to use a _development_
> environment to fix *inherent* shortcomings of a tool?
> (Shortcomings that should not be there in the first
> place!)

Why would you think so? This is just one way to
solve the problem. I would never ever use TB
for anything. I have used a basic newsreader called
tin for over 30 years now. It works fine as I have
no need for any fancy features.

Unfortunately I could not complete my experiment.
The build process jammed my Lenovo Thinkpad so bad
that it was completely stuck, probably because
of build parallelism and memory hogging.

$ grep ^proc /proc/cpuinfo
processor : 0
processor : 1
processor : 2
processor : 3
processor : 4
processor : 5
processor : 6
processor : 7
processor : 8
processor : 9
processor : 10
processor : 11

$ grep ^vendor /proc/cpuinfo |head -1
vendor_id : AuthenticAMD

I got 16GM of RAM. Maybe the build parameters in the
spec file are too aggressive for this modest laptop,
but I did not find any "make -j" invocation.

Now I have to sleep and maybe try it again tomorrow.

br,
KK

Kalevi Kolttonen <kalevi@kolttonen.fi> wrote:
> I got 16GM of RAM. Maybe the build parameters in the
> spec file are too aggressive for this modest laptop,
> but I did not find any "make -j" invocation.
>
> Now I have to sleep and maybe try it again tomorrow.

Still awake for a while. I looked at the spec file
and replaced:

../mach build -v

with

../mach build -j6 -v

Maybe in the morning we have a complete build.

br,
KK

kalevi@kolttonen.fi (Kalevi Kolttonen) writes:

> Kalevi Kolttonen <kalevi@kolttonen.fi> wrote:
>> I got 16GM of RAM. Maybe the build parameters in the
>> spec file are too aggressive for this modest laptop,
>> but I did not find any "make -j" invocation.
>>
>> Now I have to sleep and maybe try it again tomorrow.
>
> Still awake for a while. I looked at the spec file
> and replaced:
>
> ./mach build -v
>
> with
>
> ./mach build -j6 -v
>
> Maybe in the morning we have a complete build.

Thanks for doing the work and keeping us posted. I wish you a good
night and that the compilation completes just fine.

On Sat, 28 Dec 2024 00:44:10 +0100, Janis Papanagnou wrote:

> On 28.12.2024 00:22, Kalevi Kolttonen wrote:
>
>> Compiling Thunderbird should be very easy indeed when we use Linux
>> distro's package management.
>
> You expect _users_ of tools to use a _development_ environment to fix
> *inherent* shortcomings of a tool?

On Linux, there is no “development environment” versus “user environment”.
The same packaging tools work with both source code and built binaries.

Platforms like Microsoft and Apple try to build a wall between two
separate modes of using the system; Linux doesn’t.

On 28.12.2024 00:56, Kalevi Kolttonen wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>> On 28.12.2024 00:22, Kalevi Kolttonen wrote:
>>>> [...]
>>>
>>> No need to be skeptical, we live in modern ages
>>> where things have been made quite convenient for us.
>>
>> LOL. :-)
>
> My comment above was a reference to the bad old
> days when you had to manually download tar.gz packages
> and compile them to satisfy dependencies. Now the
> builds are super easy with the help of package management.

I see; you were referring to the way the technical process
works.

Personally I don't think that package managers contribute
a lot since for ordinary users it's the same whether the
package managers install a binary package or a source that
is compiled under the hood. The difference is that source
package needs a development environment (compiler, etc.)
that "ordinary users" might not have installed or may not
want to get installed (just for that).

>
>>> Compiling Thunderbird should be very easy indeed
>>> when we use Linux distro's package management.
>>
>> You expect _users_ of tools to use a _development_
>> environment to fix *inherent* shortcomings of a tool?
>> (Shortcomings that should not be there in the first
>> place!)
>
> Why would you think so? This is just one way to
> solve the problem. [...]

For a specific type of users. - The description you gave
was describing a development process; that's not something
that ordinary users would typically do (or want to do).

Your problem solving suggestion goes even farther with yet
more inherent issues that users of package managers might
not like (editing sources, bypassing standard installation
of regular updates with an own [temporary] version/branch).

Janis