Initially I would have filled this bug as "systemd-units should not require systemd" but we should really split into rpm-helper and a systemd subpackage (rpm-helper-systemd). Else anything needing rpm-helper eventually require systemd/udev. This forces us to install systemd in minimal basesystem, defeating the purpose of the splitting between basesystem-minimal & basesystem and bloating build chroots. This is due to rpm-helper > systemd-units > systemd Eg: installing dash or coreutils-doc in an empty chroot results in having systemd among 120 packages... Try with "urpmi --urpmi-root T dash -vv --debug" No suggests are involving in this. So we should do that split and alter the packages actually providing a sytemd unit to require the new rpm-helper-systemd subpackage
CC: (none) => mageia
Hmm, I was actually intending to merge systemd and systemd-units anyway as there is no real reason to have them separate in mga3. This however shouldn't affect this bug. That said, I'm not too sure what the benefit would be in splitting out rpm-helper specifically (and I don't mean what you posted above - that's obviously a benefit)... what I mean is that most of the commands in rpm-helper are related to services in some capaacity. add/del-service obviously, but add/del-user and add/del-group are typically commands needed by services too (what use is another user if you're not installing a service to run as it?) For add/del-webapp, it kinda implies we'll need a webserver in some in some capacity and thus it will already have required add/del-service. So that only leaves add/del-shell and add/del-syslog. For this, I'd much rather see us use /etc/shells.d/ and reconfigure anything that reads /etc/shells instead. This seems more like the modern way of doing things. I'd also rather see this folder be /usr/lib/shells.d/ rather than /etc/ - again emphasising the proper separation of config vs. packaging. Ass for syslogs, I'd say something similar should be done there too (more use of .d folders). Assuming this is done, there is no need for rpm to require rpm-helper at all. Only packages which make use of the macros will need it. WDYT? I reckon this seems like better engineering overall rather than introducing a sort of artificial split.
This is above my head. Should I leave it alone?
CC: (none) => nic
Thierry, there had been an answer from Colin. Is this issue still something we can and should fix?
Keywords: (none) => NEEDINFO
(In reply to Samuel Verschelde from comment #3) > Is this issue still something > we can and should fix? Assigning to the rpm stack maintainers for an answer. We could probably use a systemd maintainers group, now that Colin is less available.
CC: (none) => marja11Assignee: bugsquad => rpmstack
(In reply to Colin Guthrie from comment #1) > Hmm, I was actually intending to merge systemd and systemd-units anyway as > there is no real reason to have them separate in mga3. > > This however shouldn't affect this bug. > > That said, I'm not too sure what the benefit would be in splitting out > rpm-helper specifically (and I don't mean what you posted above - that's > obviously a benefit)... what I mean is that most of the commands in > rpm-helper are related to services in some capaacity. add/del-service > obviously, but add/del-user and add/del-group are typically commands needed > by services too (what use is another user if you're not installing a service > to run as it?) For add/del-webapp, it kinda implies we'll need a webserver > in some in some capacity and thus it will already have required > add/del-service. > > So that only leaves add/del-shell and add/del-syslog. > > For this, I'd much rather see us use /etc/shells.d/ and reconfigure anything > that reads /etc/shells instead. This seems more like the modern way of doing > things. I'd also rather see this folder be /usr/lib/shells.d/ rather than > /etc/ - again emphasising the proper separation of config vs. packaging. > > > Ass for syslogs, I'd say something similar should be done there too (more > use of .d folders). > > > Assuming this is done, there is no need for rpm to require rpm-helper at > all. Only packages which make use of the macros will need it. > > WDYT? I reckon this seems like better engineering overall rather than > introducing a sort of artificial split. Ten years later, Colin didn't see how it could be benificial to us and after that no one commented who had any opinion on this. Closing as wontfix
Resolution: (none) => WONTFIXStatus: NEW => RESOLVED