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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
