-
Notifications
You must be signed in to change notification settings - Fork 497
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't install CNI plugins to /opt #862
Comments
@kubernetes/sig-release-proposals |
@Silvanoc: Reiterating the mentions to trigger a notification: In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
BTW, other packages being provided install under |
you should file this issue against https://github.com/kubernetes/release for better visibility, currently releases use the specs there. that repo also has much lower volume of interaction than this one 😅 |
Moving these binaries would probably require updating a lot of the ecosystem to handle this though.. I will also add that sig-release generally agrees that more broadly something needs to be done about the state of debian / rpm publishing, but they're still figuring out what direction to take it going forward and could probably use more help with that. |
/area release-eng |
Hello @justaugustus ! I'm a bug triage shadow for the 1.16 release cycle and considering this issue is tagged for 1.16, I'd like to check its status. Code freeze is starting on August 29th (about 3 days from now), do you think this issue can make 1.16? |
I think that those guidelines only apply to the distribution packages, i.e. the ones that each distribution package and consider part of its distribution.
https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#optAddonApplicationSoftwarePackages |
(transferred this issue to k/release) |
@justaugustus: The provided milestone is not valid for this repository. Milestones in this repository: [ Use In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
@BenTheElder thanks for the information. Thankfully @justaugustus already did so. |
The FHS documentation is a bit too unclear, therefore the distributions are implementing it differently. In the case of Debian, the package linter (lintian) would report it as an issue. @aojea you appear to be working for SuSE. Don't you have similar policies to those of Debian or Fedora? Anyway, even if K8s doesn't care for the distribution policies, some consistency would be desirable and installing some things to |
yeah, but those policies are for the packages that are part of the distribution, this is an external package that works with that distribution, but is not released as part of it. Per example, if you have a bug with this package in a specific distro, you can't open a bug in that distro, right? They really don't know who is packaging this or who is the maintainer. These are distribution kubernetes packages, they are built and maintained by the distribution: https://build.opensuse.org/package/show/devel:kubic/kubernetes If you want to include a new package in a distribution you have to follow a process and, of course, obey the policies. Ref:
Don't get me wrong, I'm not saying we should not care about consistency and best practices, just wanted to point out the difference between a distribution package and a third party package :) |
Fully agree if thinking on OpenSuSE or Fedora. But in Debian there's not a big difference between distribution packages and properly debianized external packages (you would use Of course, SuSE and RedHat are investing resources on K8s, therefore I can understand that the
I didn't get you wrong, I just oversaw that Debian is probably the distribution handling it a bit differently here and you are right WRT OpenSuSE and Fedora. BTW, if installing to |
The packages write here because that's where kubelet / container runtimes look. |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Closing as I agree with @BenTheElder's assessment. See here to track the deprecation of /close |
@justaugustus: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
What would you like to be added:
Let RPM and DEB packages install CNI plugins under
/usr/lib/cni
,/usr/lib/cni-plugins
or similar.Why is this needed:
Current installation path for CNI plugins (
/opt/cni
) is not aligned with Debian and Fedora packaging best practices (even possibly policies).In the case of Fedora, previous versions of their packaging guidelines were explicitly stating that packages shouldn't install any files under
/opt
. For a documented reason that I cannot fully understand, they reformulated it 4 years ago in a way that IMHO made a bit unclearer, but the essence remains the same: Fedora packages shouldn't install files under/opt
.In the case of Debian there are no clear/explicit policies forbidding it, but the standard linter for Debian packages (lintian) reports it as an error in the package.
The text was updated successfully, but these errors were encountered: