From: ericonr <ericonr@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: Re: [RFC/tracking issue] deprecating -lib32 multilib system
Date: Tue, 22 Dec 2020 03:05:56 +0100 [thread overview]
Message-ID: <20201222020556.vsXmkMfqZ3RYCaXaaiJcNyDYhujkqt5aKQkT1yeLQvk@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-27337@inbox.vuxu.org>
[-- Attachment #1: Type: text/plain, Size: 1841 bytes --]
New comment by ericonr on void-packages repository
https://github.com/void-linux/void-packages/issues/27337#issuecomment-749295909
Comment:
> We will need tooling for managing these multilib prefixes. Using just xbps as it is is fairly clunky, because by default these prefixes don't have repos set up in them and so on. Especially initial setup is relatively involved.
This initial setup will be rather clunky, since it's not really possible to derive the repo path from whatever is configured in `/etc/xbps.d`; aarch64 has a completely different path from what arm uses, for example.
Just as a note for something that may not be immediately obvious, the reason we need the `/usr/lib32` symlink *as well as* the dynamic linker configuration, is that the latter affects how programs are loaded (where the linker looks for the libraries your program is linked against), while the former is a fix that will allow libraries like mesa and pulse to simply work, since they will search for things to dlopen in `/usr/lib32`.
A few concerns that came to mind now were:
- the case where a library looks for binary helpers (like PAM does, but you shouldn't have a copy of PAM in the alternate root, so it isn't a good example) in `/usr/libexec` will be kind of broken, unless one has the "native" counterparts installed and fully compatible.
- our `wine` package, specifically the `/usr/bin/wine` launcher, will need to be thoroughly fixed, but I'm not entirely sure how.
- and
> There might be packages that require wordsize-specific data files in /usr/share. These need to be found, and such files need to go to /usr/lib(32|64). This is the right thing to do either way, since they're no different from binary files, /usr/share should only contain architecture-independent data.
At least one package that I know of is aspell.
next prev parent reply other threads:[~2020-12-22 2:05 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-22 0:50 [ISSUE] tracking issue: " q66
2020-12-22 1:17 ` [RFC/tracking issue] " ahesford
2020-12-22 1:18 ` q66
2020-12-22 1:22 ` Skirmisher
2020-12-22 1:58 ` q66
2020-12-22 2:00 ` q66
2020-12-22 2:05 ` ericonr [this message]
2020-12-22 4:31 ` ericonr
2020-12-22 4:31 ` ericonr
2020-12-22 5:11 ` ericonr
2020-12-22 5:26 ` ericonr
2020-12-22 20:59 ` q66
2020-12-22 20:59 ` q66
2020-12-22 20:59 ` q66
2020-12-22 20:59 ` q66
2020-12-22 20:59 ` q66
2020-12-22 20:59 ` q66
2020-12-22 21:22 ` q66
2020-12-22 21:34 ` q66
2020-12-22 21:58 ` q66
2020-12-22 22:16 ` q66
2020-12-23 0:26 ` q66
2020-12-23 0:26 ` q66
2020-12-23 0:27 ` q66
2020-12-23 0:39 ` q66
2020-12-27 20:07 ` ericonr
2020-12-27 20:26 ` ericonr
2020-12-28 1:35 ` ericonr
2021-01-07 20:31 ` ahesford
2022-05-01 2:14 ` github-actions
2022-05-01 5:45 ` the-maldridge
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201222020556.vsXmkMfqZ3RYCaXaaiJcNyDYhujkqt5aKQkT1yeLQvk@z \
--to=ericonr@users.noreply.github.com \
--cc=ml@inbox.vuxu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).