-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
libct: internalize some packages #3049
Conversation
Hope this won't conflict with #3033 as it will be a nightmare to rebase that one. |
The package has no external users (at least according to https://pkg.go.dev/github.com/opencontainers/runc/libcontainer/capabilities?tab=importedby) and thus is a good candidate for internalization. Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Are there any objections or comments about this PR, @opencontainers/runc-maintainers? I have another PR (#3056) that is based on this one and want to move forward with it. |
I personally prefer |
First, I was hoping to make those import paths shorter (or at least not longer). Second, runc/libcontainer is used by other projects, while runc/internal clearly contains a set of packages aimed for runc itself. Are those packages about containers? Yes, they are -- the whole runc is, and no, they aren't -- say, I'd like to keep it as is (mostly because it's shorter). |
Yes, everything in runc repo is about container, but the phrase I used was Back to the old days, we only have libcontainer, then we moved it to a separate repo to build runc based According to #3028 , we are about to move most of libcontainer packages to internal, which means we are I'm happy to change my mind if there are other concerns, just shorter path isn't a compelling reason for me.
|
draft until we decide on the path. |
No consensus on the path for internal packages, so I'm closing this one. |
This moves a few packages from
libcontainer
tointernal
, so that they are no longer available to external users. This is the first step in implementing #3028.I chose
internal
over, say,libcontainer/internal
orpkg/internal
merely because of a short path.