RPM fails to update, conflicts with ?itself?. Packaging failure... #6879
Assignees
Labels
Comments
|
Just wanted to say, netdata is amazing! I'm blown away by this software. We've been using it for less than a month, and it's already saved my bacon. |
There is no haproxy plugin in netdata. Haproxy is python.d.plugin module So
Actually no. Nothing was changed since 1.16.
The only my install
@paulkatsoulakis please take a look |
|
Good morning, thank you for reporting this @nmacgreg and i am sorry you bumped into issues. Are you using our own package repository to install netdata? The reason i am asking about this is because at netdata we have not provided such a package separation (not yet at least). I will attempt to reproduce the issue until we get further feedback from your side. |
|
Hello, I had similar issues: EPEL repackages the standalone "netdata" package and splits it into 3 packages:
This broke my setup too, and I had to use the official netdata spec (as before) rename it into a new one, and add flags you can workaround it by issuing This issue is clearly one created by EPEL by changng the official specfile. Maybe we should add by default an "Obsoletes: netdata-data netdata-conf" to avoid EPEL to come into the way if users starts using the official netdata repositories / packages. |
|
Adding the |
|
Adding the obsolete flag certainly helps clean up the extra packages added by EPEL, but doesn't entirely solve the problem i think. Might worth adding some pre-install step to check whether EPEL packages are in place and remove them instead. I don't know if I recall i had used Obsoletes to deprecate stock version of a package in the past (wireshark specifically), but the new version of it was with a different name so that worked fine |
|
Not for the base It's a shame we have to do this upstream to handle a case done by a rpm provider, but EPEL should be "standard" enough to be worth the case. Could also someone contact them on behalf of netdata to ask them why they did this, and if the solution suits them too ? |
|
They are free to do anything they like, we have no say on the matter. It's one of the many reasons we opted for our own binary distros. Our responsibility is to ensure that we don't leave a user's system in a broken state. There are only two options here, either detect the other installation and abort with a very clear message, or do what you suggested. The former is, of course, nicer. Can we do it? |
|
Yes, with a scriptlet in |
|
We can also add a Also, if another package relies on an epel package (eg, a dashboard plugin or something like that), should we also add the |
mfundul
added
area/packaging
|
Hi @nmacgreg! Sorry for the late reply. Is this still an issue for you? |
|
@prologic I think this issue still exists: Note: the netdata-data and netdata-conf packages are currently installed from EPEL. |
|
@mixe3y Can you please confirm:
Thanks! |
Saruspete
added a commit
to Saruspete/netdata
that referenced
this issue
May 19, 2020
|
I'm using CentOS 7 Steps:
The cause of the issue is that netdata-data and netdata-conf is installed even after removing netdata from epel. |
|
Looks like #9108 might solve this! Thanks @Saruspete ! I will review the associated PR(s) soon. |
prologic
pushed a commit
that referenced
this issue
May 21, 2020
Saruspete
added a commit
to Saruspete/netdata
that referenced
this issue
Jun 17, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bug report summary
On nightly "yum update", netdata failed to update via RPM.
In short, many files seem to have "conflicted with themselves", including the directory /etc/netdata/. Here's one error:
OS / Environment
Under the latest CentOS, 7.6.1810 in a VM, under oVirt (eg KVM); patched nightly. We have a very limited installed base, just 6 machines for now: our Dev, Test, and Prod HAproxy servers. All were installed via Ansible. This is the first update we've ever installed; we only started using netdata Aug 1, 2019.
Netdata version (output of
netdata -V)Current version: 1.16.0
Trying to update to 1.17.1-1 via RPM, on EPEL
Component Name
netdata's RPM packages
Steps To Reproduce
This problem occurred consistently on all 6 machines on which we had it installed. I suggest, although I did not try:
Expected behavior
"yum update -y" should update to the latest version, v1.17.1, without complaint.
Failed work-around:
I was initially not awake enough to realize that netdata consists of 3 separate RPM packages. I tried just removing the most obvious "yum remove netdata -y; yum update -y; yum install netdata", but I got the same errors - conflicts with netdata-data & netdata-conf (of course).
Work-around:
I tried to remove the entire thing, then re-install it again at the newest version:
Extra credit: I ran our ansible playbook against this, to get the haproxy plugin re-activated... but I see you've also changed the structure of the directories! /etc/netdata/conf.d/ no longer exists under v1.17.1. That's unexpected, seems undocumented.
More Extra credit: Under v1.16.0, I found that by setting:
...into /etc/netdata/netdata.conf, then restarting the netdata service, it would auto-populate /etc/netdata/conf.d/ with a tree of other (config) files. It no longer does this. That original feature seemed to be undocumented.
The text was updated successfully, but these errors were encountered: