MONGOSH-692 Rename package to mongodb-mongosh

[deriamis]

The RPM and Debian packages are renamed to mongodb-mongosh to fit a
common Linux package naming convention which allows users to locate
software more easily. A Provides: tag is also added to the packages to
provide a stable naming alias in case we ever decide to rename packages
again.

[deriamis]

I don't think the test failures are due to my changes, but they are blocking package tests.

[addaleax]

@deriamis Yeah, I just restarted them, they seem to be flaky tests. If there’s more problems, we can also take care of that :)

[addaleax]

@deriamis So, I think the original idea here was to scope this to only changing the Linux rpm and deb package names, and there were quite a few tests that were relying on this, so unfortunately this has become a somewhat larger patch :)

[deriamis]

Oh, dear. I can see the reason for hesitating on this change, then.

I noticed that there's a static amd64 arch defined for the packages. Are you planning to release for any other architectures in the future? Even if not, it's better not to define that in the package definition because the tools will automatically insert that for you based on the architecture you're building on.

Also, not releasing on all architectures supported by the legacy shell means we have to do a bit more work on the Provides tags to convince the package managers to install mongosh only when it's available.

[addaleax]

Oh, dear. I can see the reason for hesitating on this change, then.

@deriamis No worries! It’s good that you’re reminding us to do this, though, especially if your work depends on it.

I noticed that there's a static amd64 arch defined for the packages. Are you planning to release for any other architectures in the future?

Yes, in the very near future actually: #850

Even if not, it's better not to define that in the package definition because the tools will automatically insert that for you based on the architecture you're building on.

Does it detect that based on the architecture the binaries are built for or the architecture where the packaging happens? The current state of #850 does that on a Docker container on x64 always, which makes our lives a bit easier.

Also, not releasing on all architectures supported by the legacy shell means we have to do a bit more work on the Provides tags to convince the package managers to install mongosh only when it's available.

Right – the plan is that we will match the current server support matrix, or at least that’s the idea behind https://jira.mongodb.org/browse/MONGOSH-424.

[deriamis]

Does it detect that based on the architecture the binaries are built for or the architecture where the packaging happens? The current state of #850 does that on a Docker container on x64 always, which makes our lives a bit easier.

You have three options: either it's detected by the architecture the package is built on (not the binaries it contains, I'm afraid), you can supply a build architecture argument to the packager, or you can put it in the package definition as you are doing now. The last two are equivalent, except the command-line option overrides whatever is in the file. If building on a single docker container is easier for you no matter what the binaries are, you need to choose one of the last two options.

Also, not releasing on all architectures supported by the legacy shell means we have to do a bit more work on the Provides tags to convince the package managers to install mongosh only when it's available.

Right – the plan is that we will match the current server support matrix, or at least that’s the idea behind https://jira.mongodb.org/browse/MONGOSH-424.

Oh, good. I was just making sure I wouldn't need to start figuring out how to work around this. I'll just leave you folks to it, then.

[deriamis]

I just realized that it would be very beneficial if we added a version string to the Provides tags. The default version string is 1, and we are going to be using the same name on the legacy shell in the server repo. This change will let us simply update the required version in one place when you're ready for release.