https://bugzilla.redhat.com/show_bug.cgi?id=1507103 --- Comment #76 from Jan Pokorný <jpokorny@xxxxxxxxxx> --- Thanks to everyone involved, also for patience; I understand that time as a main metric might be preferred to overall quality, but I tried to explain the significance of the latter for the wider "package collection". As this is one-off currently, it's believed that the reviewed version will be used as a gauge for future updates. That being said, I find just two points to be addressed prior to approval, and I am at least partially responsible for the first one: * * * re H.: I should have explained better the required change, as currently it's only partially satisfied (beside following bad instructions). Let me provide wider context: - until very recently, /sbin/ldconfig invocations were interspersed in individual spec files in %post and %postun scriptlets (execution unit triggered as the package is being installed/removed in this case), to keep the dynamic linker cached knowledge about the installed libraries current -- so far so good, this is what previous version of this spec was using - some time ago, rpm added generic support for scriptlets to be run only once per whole transaction (comprising, e.g., all your updates received in one go) - relatively recently, wise Fedora maintainers realized there can be cumulated overhead arising from running ldconfig per package, when in most cases it's enough to run it per said transaction, and introduced new "self contained" change: https://fedoraproject.org/wiki/Changes/Removing_ldconfig_scriptlets which asks either to drop ldconfig invocation from the spec altogether (Fedora 28+ only), or to use the compatibility macros (to cover also pre-28 cases, which I believe is the intention with kronosnet) The problem is that we need to address all "ldconfig" occurrences, not just the one I've mistakenly mentioned in isolation in [comment 57]. Beside the description at the above page, we can also investigate on our own: $ rpm --showrc | grep -A3 ldconfig_scriptlets > -13: ldconfig_scriptlets(n:) %{?ldconfig: > %ldconfig_post %{?*} %{-n:-n %{-n*}} > %ldconfig_postun %{?*} %{-n:-n %{-n*}} > } We can grok that %ldconfig_scriptlets will handle both %post and %postun sides on its own. Regarding usage with subpackages, there's a confirmation that currently adopted usage is OK, e.g., on devel ML: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/JZNJEN5FG5SAVQKC5RTWEJDQDLBETNI4/ Hence what I ask for: for both libtap1 and libknet1 subpackages, make sure that these occurrences in the original: > %post -n SUBPACKAGE -p /sbin/ldconfig > %postun -n SUBPACKAGE -p /sbin/ldconfig are both mapped to a single, unique line: > %ldconfig_scriptlets -n SUBPACKAGE As you can see, I mistakenly provided a bad piece of advice, actually, as using "-n SUBPACKAGE" vs. just "SUBPACKAGE" is aligned with how other macros (namely %package, but consequently %description, %files, %postun, etc.), and it's the former case with both libknet1 and libtap1. These naming subtleties are best understood here: http://ftp.rpm.org/max-rpm/s1-rpm-subpack-spec-file-changes.html#S3-RPM-SUBPACK-PACKAGE-DIRECTIVE-N-OPTION * * * Free-form implementation of > - comment above "%debug_package" that it is not relevant for > Fedora and its removal is pending [there] per [comment 73] is still missing. * * * Digimer, you are also free to cut off the older changelog entries (like up to and including 1.0-10) to make the situation perhaps a bit easier to grok, since those steps are all prior to inclusion (and hence not a game changer for downstream users), and you already demonstrated your changelog entries are spot-on. But it's merely up to you, there was certainly an undeniable effort invested since the initial version... (And if you decide to do so, there's no reason to state that very change in the changelog.) -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx
