Move golandlock under landlock-lsm

[gnoack]

Let's move golandlock into github.com/landlock-lsm, as offered by @l0kod.

Constraints:

• The imported Go package name (last part of path) should only contain letters
  • underscores not recommended, dashes don't work
  • Only applies to last path component. It can also be nested in an additional subdirectory and that wouldn't look completely wrong.
  • Prior art: the popular package github.com/go-cmp/cmp and others (I grepped my own Go imports and found a few)
• There is already github.com/landlock-lsm/rust-landlock, and naming it similarly would be logical.
• Let's move it sooner rather than later before the old location is used too much

Proposal

Let's move it to: github.com/landlock-lsm/go-landlock/landlock The name is a little bit repetitive, but:

• last path component is just "landlock" and that would read nicely when the package is being used.
• It's consistent with the location of the Rust package

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:

• move the Go packages into a new "landlock" subdirectory
• adapt the spelled-out package paths in all locations

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.

[gnoack]

@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.

[l0kod]

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 package landlock in landlock.go (renamed from golandlock.go), which should still enable us to have a github.com/landlock-lsm/go-landlock module.

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).

[l0kod]

I think the replace directive may help (if it makes sense for the module itself):

• https://golang.org/ref/mod#go-mod-file-replace
• https://github.com/golang/go/wiki/Modules#when-should-i-use-the-replace-directive

Something like this: replace github.com/gnoack/golandlock => github.com/landlock-lsm/go-landlock

Otherwise, a manual transition for developers should be something like this: go mod edit -replace github.com/gnoack/golandlock=github.com/landlock-lsm/go-landlock

[gnoack]

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 github.com/google/go-cmp/cmp uses.

The go.mod replace directive doesn't work here, I believe. That one just bends the paths for the imports done within the same module, but it doesn't redirect users from the outside.

So, proposal:

1. I removed the v1.0.0 tag (already done, to make sure no additional people accidentally pick it up; should have done it on Friday directly...)
2. Move the repo to github.com/landlock-lsm/go-landlock
3. In the new location, move the code into a subdirectory "landlock"
4. Tag it as v1.0.0 again. (This will be v1.0.0 of landlock-lsm/go-landlock, and that is distinct to v1.0.0 of the old library location)

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).

[l0kod]

OK, your plan looks good! I need more permissions to be able to move this repo to github.com/landlock-lsm though.

[gnoack]

Hmm I failed to give you more permissions than you already have...

https://docs.github.com/en/github/setting-up-and-managing-your-github-user-account/managing-user-account-settings/permission-levels-for-a-user-account-repository:

A repository owned by a user account has two permission levels: the repository owner and collaborators.

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?

[l0kod]

Yep, that should be OK now.

[gnoack]

OK, it worked this time. Next steps should be:

1. Accept the transfer, you'll find the 'golandlock' repo under l0kod.
2. Go to the repo settings, at bottom of main setting page transfer it on to the landlock-lsm org.
3. In the landlock-lsm org, rename the repo to go-landlock.
4. In case that is dropped along the way, please invite me as collaborator so that I have write access and can fix the Go module layout accordingly.

[l0kod]

Everything looks good. I'll let you s/gnoack\/golandlock/landlock-lsm\/go-landlock/g and update https://pkg.go.dev/ Thanks!

[gnoack]

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.