RFE: Allow configuring the name of the "quota" command

[jasontibbitts]

In the Fedora packaging I have to rename the "quota" command to "cyr_quota" because Cyrus 3 installs this into /usr/sbin and that's a pretty big conflict with /usr/bin/quota. This, of course, causes problems for cyrus, because the name of that executable is hardcoded in various places, usually as follows:

$self->{instance}->run_command({ cyrus => 1 }, 'quota', '-f');

I can hack around it by making some symlinks before I call the tests, but it might be less hacky to allow this and the other hardcoded binary names (especially reconstruct, which also seems prone to conflicts) to be configurable.

I'd offer a patch but I haven't yet worked my way through the Cassandane code to figure out how. I'm still trying to get the whole thing to build reliably.

[elliefm]

Seems like there might be some merit to packaging it up with prefix=/usr/cyrus instead of just /usr, at least as a patchwork? I think a lot of Cyrus's binary naming has historically assumed this to be the case, alas (see also master). The old non-standard configure options had a setting for this, but it was a precarious mess.

[jasontibbitts]

Well, using prefix=/usr/cyrus would be a FHS violation and because of that Fedora packages aren't permitted to create anything directly under /usr. Plus, that would just be a bad thing in general if all sorts of random packages did it. Fedora got rid of /usr/kerberos ages ago, for example.

But really, Cyrus still uses --libexecdir directory (which I configure as /usr/libexec/cyrus-imapd) that it uses for things like master. It's just that executables which someone might actually run like quota or restore really should be in the path, and it's a good thing that Cyrus has moved them there (except for the conflicts, of course). I asked Bron about it a while back and he indicated a general preference for renaming all potential conflicts there to have a "cyr_" prefix. I'm not sure if anything has happened on that front, though.

Anyway, I may make some symlinks in /usr/libexec/cyrus-imapd to make upgrades easier for people who expect to find those executables in that location and with the old names. I think Cassandane might actually find look for them there.

[elliefm]

Yeah, there might even be an existing issue about renaming the binaries (or, it might be one that was on phabricator and got lost when that died). I don't think anything's happened there yet, but it would be a good one to target for when 3.1 eventually gets released (I don't want to do it on the stable 3.0 series, obviously). It's an awkward one to do though, cause it could make backporting fixes between branches a bit of a nuisance.

I've just realised this issue is on the cassandane repo, not the cyrus-imapd repo, so you're asking for a cassandane option for choosing what name to look for, rather than a ./configure option for renaming the binary. Which seems heaps easier!

[elliefm]

Have just raised https://github.com/cyrusimap/cyrus-imapd/issues/2027 for the big rename project

[elliefm]

How's this: 47a0446 ?

If you add something like "quota = cyr_quota" to the [cyrus default] section of your cassandane.ini, then any time any part of cassandane tries to execute a binary called "quota", it will actually execute "cyr_quota" instead. You can set a /path/with/slashes here if you wish, otherwise it will still use the usual locating mechanism, which searches the standard cyrus directories, just with the replaced name.

[jasontibbitts]

It appears that would work. For now I've settled on just patching the calls to run_program in the relevant test but when I next refresh Cassandane (which will probably be when Cyrus 3.0.2 comes out) I'll switch to this method.

[elliefm]

I think we can close this off now?

[jasontibbitts]

I think so. I'm not using your solution yet and am still patching, but now that I'm using a newer cassandane snapshot can switch over.

[jasontibbitts]

I just dropped my patches and switched to using the new method and can verify that this works as expected.

[elliefm]

Great!