Bug#550817: thoughts on a gitolite Debian package

[Sitaram Chamarty <sitaram@atc.tcs.com>]

On Thu, Feb 04, 2010 at 08:38:49AM +1300, martin f krafft wrote:

> If the user ran easy-install, then the source files are likely to
> live on a separate machine, outside of our control. The user may not
> be aware of that fact (at least not consciously), and might not know
> that s/he is expected to react to security issues by pushing new
> versions manually.

True.  However, my concept of a workstation-originated
install in the APT case would be different from that
described above.  See below.

[snip]

> In fact, I think the easy-install script, as nice as it is, should
> not be installed by the Debian package.

as that script looks now, yes, I agree.

Easy install conceptually does 2 different things: (1) copy
the actual code to the right places, and then (2) setup the
RC file, create the initial repos (gitolite-admin and
testing), and run the install/compile scripts to setup the
authkeys file.

It's only #1 that causes the problem you described.  #2 does
not; you can have a "setup my gitolite" script that does #2
for each user who wants to host his own repos using his own
userid.

When there is an upgrade, the software (what I called #1
above) would be upgraded by APT, and even workstation
originated installs would use it so that's fine.

Like in any software, we would make sure that
backward-compat breakage in config file syntax is kept to
absolute minimum, and to make sure that any new variables
introduced to RC fie are always optional and assume safe
defaults.  This will ensure that someone who has not
upgraded their RC file or config file with new features can
still use the new *code* without harm.

Does that make sense?  I just woke up so if it doesn't, let
me know :)

-- 
Sitaram