-
Notifications
You must be signed in to change notification settings - Fork 8
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
Move golandlock under landlock-lsm #10
Comments
@l0kod Does the proposed location sound reasonable to you? If you agree with this approach, feel free to copy the repo over to the new location and ideally remove the v1.0.0 git tag in the new location (or just create an empty repo and give me write access, then I can move it too). Let me know what you think. |
I think we should move (but not copy) the golandlock repository to github.com/landlock-lsm. It is important to keep the repository as the parent/first one (for forks), the associated issues and other GitHub metadata. It also enables to automatically redirect from https://github.com/gnoack/golandlock to https://github.com/landlock-lsm/go-landlock which could help manage the transition, even for the current users. However, this redirection will vanish once a new repository with the same name will be created back in https://github.com/gnoack. It may not be a bad thing if it breaks Go programs using this module, it would force the developers to investigate and rename the dependencies. What do you think? I would prefer to keep the v1.0.0 tag. I guess we can create a new v1.1.0 tag with the new package and module names. According to https://github.com/seccomp/libseccomp-golang it seems that we can have a Thanks to the GitHub URL redirection and the go.mod file, there may be a way to smoothly transition to the new repository. It may be required to keep the golandlock.go file or create a symlink but I don't know how Go would behave (keeping in mind that this library only make sense on Linux, and should most likely be on a filesystem supporting symlinks). |
I think the
Something like this: Otherwise, a manual transition for developers should be something like this: |
In Go, modules (=libraries) are really identified by their full locations, so by just moving (and not updating) the repo to a different place, we might break it temporarily, but it's good enough. On the other side, I don't think it has that many users yet, and just breaking existing users is probably less work for them to update than for us to figure out how to do this correctly. I removed the v1.0.0 tag in golandlock for now. This is strictly speaking not the correct thing to do, as it might break users who have started using v1 over the weekend, but I'm hoping that we don't have that many users yet. (At least on godoc.org it doesn't show any known users in the indexed open source Go programs) I looked at the seccomp example you found, and I wouldn't want to do the same thing they've done. The import path has a dash in the last path component, effectively forcing all users to "rename" the package at import time (because a package name with a dash is not a valid identifier in Go). I still think it's better to use the structure as The So, proposal:
This effectively leaves the old github.com/gnoack/golandlock package location in a broken state, but as you said above, it can be overridden with a new repository with the same name if it's really needed (I suspect it's not). |
OK, your plan looks good! I need more permissions to be able to move this repo to github.com/landlock-lsm though. |
Hmm I failed to give you more permissions than you already have...
I tried to transfer it using the instructions in https://docs.github.com/en/github/administering-a-repository/managing-repository-settings/transferring-a-repository but it seems that for that I need to have write access to add repos to github.com/landlock-lsm . (I'd obviously only need it temporarily and keep my hands off the other stuff.) There is another thing that might work, which is that I transfer the repo to l0kod (in that case, you just need to approve that), and then you can transfer it on from your own account. You should have an email about that. It's a little bit more complicated with the additional step, but it might work. If everything fails, I have a local copy of the git repo here %-) Edit: Got an error that a repo with the same name already exists for the l0kod user. If you didn't receive an email, could you remove that one? |
Yep, that should be OK now. |
OK, it worked this time. Next steps should be:
|
Everything looks good. I'll let you |
And done :) It builds and the package paths look nice. I'll let it bake here a bit to check that I didn't introduce additional failures, and then tag it v1 again. |
Let's move golandlock into github.com/landlock-lsm, as offered by @l0kod.
Constraints:
Proposal
Let's move it to: github.com/landlock-lsm/go-landlock/landlock
The name is a little bit repetitive, but:
What we'd need to do
Copy the repo into the desired location. Important: We should remove the git tag while doing so, so that the Go tooling doesn't interpret the new location as a stable Go module.
(I suspect that the right way to copy this over is like this: https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/creating-a-repository-on-github/duplicating-a-repository so that it's not a "fork" in the Github sense, but stays disconnected from the original location?)
In the new git repo:
In the old git repo: Add a big warning pointing to the new location.
Alternatives considered
There is also https://docs.github.com/en/github/administering-a-repository/managing-repository-settings/transferring-a-repository If I'm reading this correctly that would make the repo accessible under both the new location and the old location (as redirect). I suspect that wouldn't play well with the Go tooling, where the modules spell out their own location in some places.
The text was updated successfully, but these errors were encountered: