[WIP] ncm-spma: yumdnf: use spmaleaves dnf plugin#1507
[WIP] ncm-spma: yumdnf: use spmaleaves dnf plugin#1507stdweird wants to merge 8 commits intoquattor:mainfrom
Conversation
stdweird
changed the title
stdweird
force-pushed
the
yumdnf_spmaleaves
branch
5 times, most recently
from
530d822 to
edaa99f
Compare
| push our @ISA , qw(NCM::Component::spma::yum); | ||
|
|
||
| use constant YUM_CONF_FILE => "/etc/dnf/dnf.conf"; | ||
| use constant YUM_CONF_CLEANUP_ON_REMOVE_VALUE => 0; |
There was a problem hiding this comment.
this is potentionally dangerous; and i was surprised it was enabled on yum.
the usual scenario is that a (installed) leave has a (installed) dependency on something you have listed in the packages list (but the leave itself is not listed; only the dependency). the current code will generate a remove command for the leave, and no install command for the dependency (it's already nstalled). autoremove will remove the leave and the dependency; and you will end up with something you didn't ask for.
Sounds like the right approach - nice to see this functionality being maintained by someone other than us - but it appears to be part of RH maintained dnf-plugins-core so why would we need to make our own rpm rather than getting it from OS? |
|
@ned21 yes and no. most of the code is the same, but the output is different from the leaves plugin. also, the el8 rpm for dnf-plugins-core does not include the leaves plugin at all (and it looks intentional). |
That's a bit odd. Can you ping me some details on where you seeing it's missing and why you think it's intentional and maybe I can raise a support case asking them to add it? (Or do we need a different plugin of the same name? That's confusing... But again maybe we can ask for RH about it.) |
|
e.g. https://git.centos.org/rpms/dnf-plugins-core/blob/c8s/f/SPECS/dnf-plugins-core.spec#_226 but tbh, without rpm-software-management/dnf-plugins-core#399 and a way to change the format of the of showing the results (we need only need the name and the arch; and must be able to identify the scc somehow (see eg the PR; but ideally in a more machine readable version like the version i used)) it's pretty pointless. |
|
As you stated that you have no expectation for this to ever be merged I've converted this PR to a draft. |
…tly modified output
… spma can't try to fix it)
stdweird
force-pushed
the
yumdnf_spmaleaves
branch
from
373d5ab to
22c9bc6
Compare
We could of course ship the plugin as a separate RPM in the externals repo and have ncm-spma depend upon it. |
That sounds like an excellent idea to me. It's just this one python file (the leaves plugin itself) which is slightly adjusted from upstream if I understand it correctly? Can we make a dedicated repo for the plugin and spec file? Or do we have some other place to put it? |
|
I'd be tempted to try and get the now very small changes merged upstream if possible. |
|
I've tried out this PR/WIP, and there are problems when dealing with several architectures of a same package. For example, if the package glibc-gconv-extra is installed with 2 architectures (i686 and x86_64), spma will remove both as they are not declared in /software/packages and userpkgs is set to 'no', but doing so, it also removes all Quattor and perl packages. The full story is the following: glibc-gconv-extra is a dependency of redhat-rpm-extra that is itself a dependency of perl (via perl-devel). You can remove one arch of glibc-gconv-extra, but not both. |
5 participants
Requires #1401