[haiku-bugs] Re: [Haiku] #15828: Add automatic path remapping in packages in secondary architectures
- From: "Haiku" <trac@xxxxxxxxxxxx>
- To: undisclosed-recipients: ;
- Date: Wed, 25 Mar 2020 11:59:54 -0000
#15828: Add automatic path remapping in packages in secondary architectures
--------------------------------------+----------------------------
Reporter: X512 | Owner: bonefish
Type: enhancement | Status: reopened
Priority: normal | Milestone: Unscheduled
Component: File Systems/packagefs | Version: R1/Development
Resolution: | Keywords:
Blocked By: | Blocking:
Has a Patch: 0 | Platform: All
--------------------------------------+----------------------------
Changes (by pulkomandy):
* status: closed => reopened
* resolution: invalid =>
Comment:
Linux distros avoid this by having *all* libs and included in arch
subdirs, which has other downsides we decided not to go with.
Cication needed, what are the downsides? I can't think of anything
obvious.
In theory, software once made should be possible to run forever in
originally packaged form.
I would love to live in Theory, because in Theory, everything goes well.
There are many things that get in the way of achieving this, and at some
point, alternate solutions end up being better. For BeOS apps, these
include:
- Getting the source to the app and patching it,
- Running it in a virtual machine,
- Rewriting a replacement (or better) application,
- Patching the binaries.
All of these would be unrealistic for Mac OS X or Windows because they
have so many applications. The first one is essentially what Linux does,
with the Linux distributions putting all their resources and efforts into
it. In our case, there are not that many BeOS applications, which mean we
can afford in some cases to be less compatible and patch the applications
instead (ideally we would detect the binary and live-patch it or
something).
This is not to say we should completely give up on compatibility, but at
some point we have to drop the oldest things. Even Microsoft has dropped
support for 16bit applications (Win16) and DOS applications in modern
Windows.
What we should aim for is a platform that supports and runs existing
binaries long enough that distributing binaries is a reasonable way to do
thing. How long is long enough? It depends on the ecosystem.
BeOS is not perfect in terms of future-proofing, they made a quite good
try, but there are limitations to their approach. We could set up
ambitious plans to keep things working at all costs, for example,
implement the gcc2 ABI in clang so we can use a modern compiler to build
support libraries for BeOS apps. But it is worth the effort? Or will it
end up being simpler to recreate the few affected apps?
I see the BeOS comaptibility as a way to train ourselves on what binary
compatibility means, and to learn how to forward-proof our new
developments. So, I think we should make best-effort compatibility with
BeOS, for as long as reasonably possible, and learn from the limitations
of what they did, and see if we can avoid hitting the same problems.
--
Back on-topic now. Should this be done in packagefs? Or in the
runtime_loader? Or maybe both need to collaborate? Do we need a new
package format to make this simpler? Change to the buildtools?
Maybe it will end up being moved to Haiku R2 because it can't be done for
BeOS apps but only for packaged Haiku R1 ones. But that is no reason for
closing the ticket, there is a valid use case here and things to talk
about.
--
Ticket URL: <
https://dev.haiku-os.org/ticket/15828#comment:9>
Haiku <
https://dev.haiku-os.org>
The Haiku operating system.
Other related posts:
