| Summary: | [BLOAT] rpm-helper should be split in rpm-helper + rpm-helper-systemd | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Thierry Vignaud <thierry.vignaud> |
| Component: | RPM Packages | Assignee: | RPM stack maintainers <rpmstack> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | mageia, marja11, nic |
| Version: | Cauldron | Keywords: | NEEDINFO |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | rpm-helper | CVE: | |
| Status comment: | |||
|
Description
Thierry Vignaud
2012-06-08 14:33:01 CEST
Thierry Vignaud
2012-06-08 14:33:07 CEST
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) =>
marja11 (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) =>
WONTFIX |