Netdata agent package name conflicting with EPEL package. #12331
Replies: 6 comments 12 replies
-
Alternatively, it looks like DNF and YUM support setting repository priorities (requiring a plugin in the case of YUM), which override version number checks. At the time when I was creating the repository configuration packages, I had not know about this, so we don’t actually use it currently, but setting our own repository priority to a sufficiently low value such as 50 (default is 99) should resolve this without needing to shuffle package names. |
Beta Was this translation helpful? Give feedback.
-
Formally documenting the options here, along with the pros and cons I see, in preparation for asking the product team for an opinion on this in the hopes of resolving the ideological deadlock on this... Rename the packageMost likely new name would be Pros
Cons
Set a high repository priority for our package repositoriesPros
Cons
Explicitly exclude netdata packages from consideration in EPELPros
Cons
|
Beta Was this translation helpful? Give feedback.
-
I disagree that using the priorities is either good or desirable.
7. A Cautionary Note
[image: <!>] Note: The upstream maintainer of yum, Seth Vidal, had the
following to say about 'yum priorities' in September 2009:
Gosh, I hope people do not set up yum priorities. There are so many
things aboutpriorities that make me cringe all over. It could just be
that it reminds me ofapt 'pinning' and that makes me want to hurl.
[image: <!>] This matter was discussed in more depth in the mailing list
thread starting here
<http://lists.centos.org/pipermail/centos/2009-November/086189.html>. The
Repositories <http://wiki.centos.org/AdditionalResources/Repositories> article
noted in that thread, which discusses the exclude and includepkg options for
yum, is a better place to start in understanding priorities.
The primary concern is that priorities is heavy handed over removing
packages from the transaction set. It makes it difficult to readily
determine what packages are being ignored and why. Even so, it is very
flexible and can be extremely useful to provide the largest available list
of packages.
…On Mon, Mar 14, 2022 at 5:36 PM Costas Pipilas ***@***.***> wrote:
From the product point of view, I would be in favour of the second option
(Set a high repository priority for our package repositories):
- Transparent for users
- Controlled side-effects
- Enforcing ordered protection of repositories decreases potential
reliability/maintainability issues
—
Reply to this email directly, view it on GitHub
<#12331 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAOOJNNT4XUJ3CUDELNP7SLU75MJLANCNFSM5QDESFPQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
Regards,
--
Igor
|
Beta Was this translation helpful? Give feedback.
-
Just a remark. We do install EPEL on RHEL 7 systems anyway, because the
netdata package depends on the packages in it. Judy, libuv, etc. Even RHEL
8 has one package (and its dependencies) from EPEL. I opened another
discussion about the possibility to replace netcat with nmap-ncat in order
to get rid of EPEL on RHEL 8. (Here I assume that Rocky is almost identical
to Centos/RHEL.)
As for the rest, I suggest closing the discussion. I stand by my opinion,
though.
…On Wed, Mar 16, 2022 at 4:39 PM Austin S. Hemmelgarn < ***@***.***> wrote:
I’m not saying that priorities are a good or even desirable solution, I’m
arguing that they are the only option that actually solves this issue for
all affected users.
We *CAN NOT* persistently exclude the Netdata packages from EPEL, because
doing so requires modifying the EPEL repository configuration on the system
itself, which in turn requires us to install EPEL if it is not installed
even if we do not otherwise depend on it.
We *SHOULD NOT* rename the the packages, because doing so does not
actually solve anything for existing users, impacts *all* users
negatively whether they are affected by this issue or not, adds a
nontrivial maintenance burdern for us, and may eventually not actually
solve the issue at all (because Fedora (the source for EPEL) and other
distros may just change to match anyway).
—
Reply to this email directly, view it on GitHub
<#12331 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAOOJNLGEFMX6AMJA2VTLSDVAHXBHANCNFSM5QDESFPQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
Regards,
--
Igor
|
Beta Was this translation helpful? Give feedback.
-
I suggest exactly what I suggested - renaming the package. Sorry if I did
not myself clear.
As for the rebuke about the age of the view I cited about the
undesirability of using priorities, I will say two things.
1) It was about Centos/RHEL7. It came out just in 2009. It has hardly
changed enough since then for the statement to no longer be relevant.
Otherwise this quote would have been removed from Centos wiki years ago.
2) It was said by the person who was developing yum at the time. I think I
wouldn't be wrong in assuming that he had a pretty good grasp of the
subject.
The situation, as I wrote, is much more complicated than it seems. In
addition to priorities, there are the 'costs' that I mentioned. Costs also
affect the installer's decision about which package to choose.
Consequently, the use of priorities does not provide a hundred percent
guarantee, being a potential source of confusion.
There is nothing wrong with using exclusive names. Many companies do this.
For example, the ISC version of their BIND package is called isc-bind-bind.
And there is also isc-bind-bind-utils. The same goes for DHCP.
And last but not least. You can't treat the user's computer as if it were
your own. Ideally, interference with the configuration should be minimal.
The Netdata agent is just a monitoring utility. Don't act like it's the
center of the world. It is not.
…On Wed, Mar 16, 2022 at 3:17 PM Ilya Mashchenko ***@***.***> wrote:
@iigorkarpov <https://github.com/iigorkarpov> that is a quote from 2009.
Not really an argument.
- you strongly disagree with using priorities.
- you suggest using explicitly exclude Netdata package from
consideration in EPEL - this won't do according to @Ferroin
<https://github.com/Ferroin> (see Cons).
So what do you think we need to do? If you think that excluding Netdata
packages is a way to go, then what do we do with the Cons?
—
Reply to this email directly, view it on GitHub
<#12331 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAOOJNNDIOTJWFFXDTJDUBLVAHNPVANCNFSM5QDESFPQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
Regards,
--
Igor
|
Beta Was this translation helpful? Give feedback.
-
The name of the netdata agent package is the same as the package name used in EPEL. Given that EPEL is an extremely popular repository, this overlap is fraught with serious problems for inattentive/inexperienced administrators. Routine updates of packages in the system may (depending on the current versions) lead to replacing one build with another. It is highly probable that this will cause the package to stop working.
We probably cannot influence the creators of the package for EPEL. In that case, we should consider changing the name of our own package.
# yum list | grep netdata netdata.x86_64 1.33.1-1.el7 @netdata netdata-repo.noarch 1-1 @/downloads9IDpg netdata.x86_64 1.33.1-2.el7 epel netdata-conf.noarch 1.33.1-2.el7 epel netdata-data.noarch 1.33.1-2.el7 epel netdata-debuginfo.x86_64 1.29.3-1.el7 netdata netdata-freeipmi.x86_64 1.33.1-2.el7 epel netdata-plugin-freeipmi.x86_64 1.33.1-1.el7 netdata netdata-repo-edge.noarch 1-1 netdata
Beta Was this translation helpful? Give feedback.
All reactions