* Rich Freeman <CAGfcS_neh=gu+16mo7gLRWVtHoSs2hBirvFVR_G50yJWRckHGQ@mail.gmail.com> :
Wrote on Tue, 12 Sep 2023 05:18:51 -0400:
On Mon, Sep 11, 2023 at 10:34 PM orbea <orbea@riseup.net> wrote:
Regardless the disappointment is a valid concern when Gentoo is willingAs a complete outsider, I think this conversation is focusing on the
to pull the rug up from under users feet under erroneous claims of the
project being dead.
wrong issue.
IMO the main reason it is getting treecleaned is the lack of a
maintainer. Everything about this entire back-and-forth screams lack-of-maintainer.
One of the planned consequences of this tree-cleaning is the removal
of genkernel, and the use of genkernel to build gentoo's initramfs.
Genkernel uses eudev for udev, and it works because eudev can be built statically.
systemd-udev cannot be built as a static binary again presumably a
carefully thought out design decision behind its design and
philosophy.
eudev works perfectly well for the job genkernel does, udev is not a
drop-in replacement for udev in genkernel initramfs because it doesn't support static compilation. Removing eudev leads to a roadmap to
deprecate genkernel last-rite and remove it.
Gentoo actively removes support for individual configurations, and only supports is for configurations that fedora has already engineered and controls because that is where the devs seem to be coming from.
One of the planned consequences of this tree-cleaning is the removal
of genkernel, and the use of genkernel to build gentoo's initramfs.
Genkernel uses eudev for udev, and it works because eudev can be built statically.
systemd-udev cannot be built as a static binary again presumably a
carefully thought out design decision behind its design and
philosophy.
eudev works perfectly well for the job genkernel does, udev is not a
drop-in replacement for udev in genkernel initramfs because it doesn't support static compilation. Removing eudev leads to a roadmap to
deprecate genkernel last-rite and remove it.
I know you are a dracut user, but I've been unable to use dracut with
1. cryptsetup swap + swsuspend + zfs on root.
Gentoo actively removes support for individual configurations, and
only supports is for configurations that fedora has already engineered
and controls because that is where the devs seem to be coming from.
Madhu <enometh@meer.net> writes:
systemd-udev cannot be built as a static binary again presumably a carefully thought out design decision behind its design and
philosophy.
Since static linking is seldom a good idea, it is more likely that
simply nobody bothered. I don't recall any udev components in systemd
v249 (which is the version I attempted to rebase eudev on top of) which
can't be static linked.
On Thu, Sep 14, 2023 at 10:25 AM Arsen Arsenović <arsen@gentoo.org> wrote:
Madhu <enometh@meer.net> writes:
systemd-udev cannot be built as a static binary again presumably a
carefully thought out design decision behind its design and
philosophy.
Since static linking is seldom a good idea, it is more likely that
simply nobody bothered. I don't recall any udev components in systemd
v249 (which is the version I attempted to rebase eudev on top of) which
can't be static linked.
The main issue is symbol conflicts with several major projects.
systemd makes careful use of ELF symbol visibility (hidden symbols) to prevent conflicts when libudev or libsystemd are linked with other
projects.
As I understand it, it is up to the linker to apply any visibility
rules. This doesn't work for static libs since the linker isn't
actually involved in their creation. A static library is really just
an archive with a bunch of unlinked ELF objects.
Since the symbol visibility rules are not applied, attempting to link
against libudev.a or libsystemd.a leads to symbol conflicts in
packages like LVM2 and cryptsetup. There are some Gentoo bug reports
about this, but I can't find them immediately.
The systemd project (upstream) has chosen not to work around these
conflicts by renaming symbols, and instead chooses not to support
static linking at all. They see static libs as being defective by
design. If the symbol visibility issue could be resolved at the
toolchain level, they would probably be more willing to support it.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 546 |
Nodes: | 16 (2 / 14) |
Uptime: | 00:48:23 |
Calls: | 10,385 |
Calls today: | 2 |
Files: | 14,057 |
Messages: | 6,416,573 |