Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#63961 - [dracut] Consider pulling patches from Fedora
Attached to Project:
Arch Linux
Opened by Emil (xexaxo) - Monday, 30 September 2019, 11:07 GMT
Last edited by Eli Schwartz (eschwartz) - Wednesday, 02 October 2019, 02:06 GMT
Opened by Emil (xexaxo) - Monday, 30 September 2019, 11:07 GMT
Last edited by Eli Schwartz (eschwartz) - Wednesday, 02 October 2019, 02:06 GMT
|
DetailsDescription:
Fedora dracut packaging has multiple patches, some of which remove various dependencies. Others (like the spec file) removes hooks for "irrelevant" CPU architectures. Can we pull those in please? In general, it would be great and check the (opt) dependencies of dracut. Seems like we're missing some parts. [1] https://src.fedoraproject.org/rpms/dracut/blob/master/f/0024.patch hostname, part of inetutils [2] https://src.fedoraproject.org/rpms/dracut/blob/master/f/0009.patch iscsid, part of open-iscsi Additional info: * package version(s) 049-3 Steps to reproduce: 1. Install dracut 2. Check that any of the two hooks kick in, and you're missing the dependency 3. Observe the warning/error message missing X, when the X is not listed as (opt)dependency in the packaging |
This task depends upon
Closed by Eli Schwartz (eschwartz)
Wednesday, 02 October 2019, 02:06 GMT
Reason for closing: Not a bug
Additional comments about closing: "Can we apply patches to our package on the rationale that distro X does too" is NEVER a valid reason to open a bug report, and isn't even a valid reason to open a feature request. It is the kind of reason that *PER DEFINITION* will get rejected and closed. It is not, in fact, even "a" reason, unless you are a herd animal. (Quick check: are you a hoofed mammal or other grazing ungulate?)
Depending on the case, asking for specific patches to be imported or upstream changes to be backported can be and often is valid, however those must be evaluated on a case by case merit. "It removes a dependency or optional dependency" does not seem like excellent justification.
Wednesday, 02 October 2019, 02:06 GMT
Reason for closing: Not a bug
Additional comments about closing: "Can we apply patches to our package on the rationale that distro X does too" is NEVER a valid reason to open a bug report, and isn't even a valid reason to open a feature request. It is the kind of reason that *PER DEFINITION* will get rejected and closed. It is not, in fact, even "a" reason, unless you are a herd animal. (Quick check: are you a hoofed mammal or other grazing ungulate?)
Depending on the case, asking for specific patches to be imported or upstream changes to be backported can be and often is valid, however those must be evaluated on a case by case merit. "It removes a dependency or optional dependency" does not seem like excellent justification.
If the patch is important, it will be upstream or must be sent upstream, we do not YOLO import downstream modifications for every trivial little nitpick you have.
If the patch is upstream but upstream has no concept of release management, to the point where a Fedora-run project is packaged in Fedora with 26 different patches because there is no release and no idea of what is important to be released, we are not going to backport every trivial little nitpick you have, nor are we just going to YOLO package git master (which seems to be basically what Fedora is doing) in order to pull in an unvetted collection of unstable patches with very little rationale, if any.
If you have accidentally visited "Arch Linux" thinking we are in fact "YOLO Linux", maybe it would be better to switch to a more trigger-happy, patch-happy distribution.
FS#62732for more requests, and responses, on why we don't randomly run from git master. As well as some analysis on what is going on with Dracut upstream.