Open elliefm opened 7 years ago
Dug through my IRC logs to find the conversation from April 20-21 where @brong said:
@tibbs: I'm in favour of renaming everything with cyr at the front and probably the things with ctl* should be renamed cyr_ as well I could post the whole thing if context is needed but I generally avoid posting logs just in case someone objects. Hopefully that's enough to refresh the various memories.
@jasontibbitts, When I was in Melbourne a few months back -- Docathon days -- @brong @nicolan & I chatted about this; that Cyrus should stop pretending it owned the name space. The options we saw were those reflected in the various packaging choices:
At that time @brong seemed to lean towards the latter, and then a few days later made the comment above.
Having spent a lot of time wending through the man pages, my only concern about any of these changes is that we would need to update those to maintain harmony with the command names. Not that tough of a task, however, but one which requires more attention than a simple "sed -i -e 's/command/cyr_command/' *.rst
" (yeah, not complete, but you get the idea).
In other words, this act will require some careful planning and coordination with packagers like yourself. Obviously, for example, if we rename reconstruct
to cyr_reconstruct
then your packaging no longer needs to. I've worked extensively with the Debian packaging, and know that there's a lot to be changed there.
Perhaps a plan for the 3.1.0 timeframe. -nic
[This might be a duplicate, but I have a hunch that the original issue was in phabricator and probably got lost when that died.]
A bunch of our binary names conflict with other packages -- 'master', 'quota', probably some others that I can't think of right now. This isn't a problem for people who install Cyrus to like /usr/cyrus or whatever, but for distribution package managers who need it to be installable in /usr, it can cause issues.
We've talked before about adding the
cyr_
prefix (or similar as appropriate) to stuff that doesn't already have it, but never actually done it.We shouldn't do this on any existing stable branches, but it would be a good one to target for the next major release.
Caveat: it might make backporting fixes to older branches more of a hassle