Hey David. I've seen you've moved the config file to /etc in 3.6.3-2. Maybe one can continue this and make gitolite3 more FSH compliant. The obvious next thing would probably be to move ~git/.gitolite/logs/ to /var/logs/gitolite3 (respectively symlink it) and perhaps to add proper logrotation config. For any other config (especially that in ~git/.gitolite/) I'd say it shouldn't go to /etc/ as it's not the canonical configuration but rather the current internal state of gitolite's config (i.e. "compiled" from whatever the user pushed from the admin repo). What I did there, personally, is that I basically created a clone of the admin repo in /etc, i.e. /etc/gitolite (well actually I've named it /etc/local/gitolite to avoid any future conflicts). Not sure if this seems like a proper way to go for the package, i.e. that it automatically creates a clone a /etc that the user may use. Further, there's "projects.list"... not sure whether this is rather variable state date or configuration. Cheers, Chris.
Christoph Anton Mitterer <calestyo@scientia.net> writes: BTW, this version is wrong. http://gitolite.com/gitolite/gitolite.html#appendix-3-v3.6.1-syslog At the moment I don't see an elegant way of changing defaults in gitolite.rc; I'll discuss that with upstream. In general I prefer to avoid divergence from upstream, unless there is a contradiction with policy MUST. For me it also doesn't make sense to force the day to day administration (editing of config, adding/deleting user keys) to use root on the server. Having files in /etc/ editable by non-root is also a bit strange (and what user should be able to edit them?).
Christoph Anton Mitterer <calestyo@scientia.net> writes: BTW, this version is wrong. http://gitolite.com/gitolite/gitolite.html#appendix-3-v3.6.1-syslog At the moment I don't see an elegant way of changing defaults in gitolite.rc; I'll discuss that with upstream. In general I prefer to avoid divergence from upstream, unless there is a contradiction with policy MUST. For me it also doesn't make sense to force the day to day administration (editing of config, adding/deleting user keys) to use root on the server. Having files in /etc/ editable by non-root is also a bit strange (and what user should be able to edit them?).
Control: notfound -1 2.3-1 Control: found -1 3.6.4-1 hmm weird... no idea how I got that in ^^ Sure.. the point is just, Debian should do that perhaps out-of-the box. Maybe simply symlink the logs dir? Well I guess we're at a corner case here: The policy, IIRC, says that FHS must be followed (more or less)... FHS in turn says: configuration goes to /etc. Obviously gitolite has two kinds of config: 1) the canonical config which can be anywhere in any number of admin repo clones 2) the current state of the config (which IMHO should really be in /var, as it is). Sure... one could also simply say, that gitolite doesn't have that classic in-/etc as in (1) above... and that we keep things here as is, and define no standard location which the user may not use anyway. Cheers, Chris.
David Bremner <david@tethera.net> writes: According to Sitaram, new versions of gitolite3 are guaranteed to be upwardly compatible with the older gitolite.rc, and gitolite-setup will not modify an existing rc file, so we could ship a debian version of the rc file and link that into the gitolite users homedir. I suspect this could actually result in simpler postinst scripts, but I haven't tried it yet. d
I'm a bit confused now what you mean. Isn't that what you're doing already anyway since last version: $ ls -al /var/lib/gitolite3/.gitolite.rc lrwxrwxrwx 1 root root 26 Dec 7 03:11 /var/lib/gitolite3/.gitolite.rc -> /etc/gitolite3/gitolite.rc Or do you mean now a modified version, that points logs to /var/log? Cheers, Chris.
Christoph Anton Mitterer <calestyo@scientia.net> writes: I mean a modified version, which enables syslog logging. this is not really the same as /var/log.
Ah, I see.. :-) Well maybe we can have both? - the default to syslog - symlink of ~/.gitolite/logs/ to /var/log/gitolite + a logrotate.d snippet, that keeps /var/log/gitolite tidy So the user can easily switch between what he prefers (syslog vs. plain files) Cheers, Chris.