Project

General

Profile

Bug #2638

[systemd] remove from base-devel group

Megver83 - about 1 month ago - . Updated 20 days ago.

Status:
confirmed
Priority:
bug
Assignee:
-
% Done:

0%


Description

Our systemd version from [libre] is in the base-devel group, however, Arch's doesn't

This is a problem since users without systemd who wish to install the base-devel group will have to pass the --ignore flag in pacman

It's also problematic for librechroots, as base-devel packages are mandatory for them, then if I want to build a pkg that conflicts systemd I just cannot do it (In my specific case I use a little hack to install all base-devel pkgs except for systemd)

The solution is as simple as removing the 'groups' variable in the PKGBUILD

History

#1

Updated by bill-auger about 1 month ago

'systemd' is already pulled in by 'base' via
'systemd-sysvcompat' and 'systemd-udev'; and 'base' is intended
to be mandatory for every system - that would explain why it
is not in arch 'base-devel' - no package in arch would need an
explicit dependency on 'systemd', because it is mandatory

im not certain exactly why, but i assume that 'systemd' is
required by parabola's 'base-devel', because some other tool
in 'base-devel' would fail without it, but does not have the
explicit dependency - so it could be that simply removing
'systemd' from 'base-devel' would cause problems for nonsystemd
systems anyway

[nonsystemd] has a 'systemd' provider - that is supposed to
eliminate any such conflicts - if something would be broken
with the dummy 'systemd' provider, i guess there would need to
be a new 'nonsystemd/base-devel' meta-package, which omits
whatever packages that need the real 'systemd'

#2

Updated by Megver83 about 1 month ago

bill-auger wrote:

'systemd' is already pulled in by 'base' via
'systemd-sysvcompat' and 'systemd-udev'; and 'base' is intended
to be mandatory for every system - that would explain why it
is not in arch 'base-devel' - no package in arch would need an
explicit dependency on 'systemd', because it is mandatory

there are thousands of packages in Arch that depend in systemd, just run pacman -Sii systemd

im not certain exactly why, but i assume that 'systemd' is
required by parabola's 'base-devel', because some other tool
in 'base-devel' would fail without it, but does not have the
explicit dependency - so it could be that simply removing
'systemd' from 'base-devel' would cause problems for nonsystemd
systems anyway

that's nonsense, how would it cause problems in non-systemd systems? I build all elogind-dependant packages in chroots with [nonsystemd] enabled which don't install systemd and none of the base-devel tools fail, I don't why assuming that systemd is needed in such case

[nonsystemd] has a 'systemd' provider - that is supposed to
eliminate any such conflicts - if something would be broken
with the dummy 'systemd' provider, i guess there would need to
be a new 'nonsystemd/base-devel' meta-package, which omits
whatever packages that need the real 'systemd'

that's not necessary

#3

Updated by bill-auger 20 days ago

i think i was just trying to find out why it systemd in
base-devel at all, if it is not in arch base-devel - then who put
it there, and why? - maybe it was added in unnecessarily,
cargo-cult style; but presumably there was a specific reason why
- i can not imagine what that would be; but it may e a
good idea to find out, in case that removing it breaks something

the depends array in PKGBUILDs do not need to specify anything
in base-devel; because base-devel is assumed to be installed
before running makepkg - likewise, there should be no need
for systemd to be in any PKGBUILD, because it is required by
'base', and 'base' is not only assumed to be installed, it is
considered to be mandatory for every system - we correct for
that with nonsystemd/base, so that makes two reasons why systemd
should not be required by base-devel - but it is assumed, indeed
required, to be installed in every arch system; so it is possible
that something will be broken by removing it, because that
"something" may actually depend on it, but would not have an
explicit dependency specified on it

im not sure if there is any easy way to find out either - we may
need to just remove it and keep an eye out for any build tools that
break for strange reasons

Also available in: Atom PDF