[PATCH] Consolidated patch to install contrib/ on posix platforms

Giorgos Keramidas keramida at ceid.upatras.gr
Sun Sep 9 17:18:32 CDT 2007


On 2007-09-09 17:09, "Jonathan S. Shapiro" <shap at eros-os.com> wrote:
>On Sun, 2007-09-09 at 15:56 -0500, Will Maier wrote:
>>On Sun, Sep 09, 2007 at 04:22:14PM -0300, Alexis S. L. Carvalho wrote:
>>> I think you can make a good argument that hgk should be installed
>>> somewhere, since hgext/hgk.py depends on it, but I'd rather let
>>> distributions decide where to install the other files, _if_ they
>>> want to install them.
>>
>> +1; we (OpenBSD) don't want to install most of the stuff in
>> contrib/. If anything changes, it'd be nice to not have to make our
>> OpenBSD-specific patch to setup.py any larger. This sort of
>> packaging seems to be best handled by distributors like OpenBSD or
>> Fedora, not centrally in hg.
>
> I can understand that point of view, but I think it is wrong. Let me
> explain why:
>
> Initially, I thought I would fix this with a patch to the RPM spec file
> (which is essentially what you propose). The problem with this is that
> the stuff in contrib/ really isn't optional for a useful mercurial
> install. hg-login and hg-ssh come to mind, but also hgk.

This doesn't mean that hardcoded installation paths would make them
easier to integrate with any random OS.  Of course, even if Mercurial
*does* install them somewhere (i.e. like the default GNU Emacs 'install'
target does), then OpenBSD, FreeBSD, Debian, SuSE or anyone else would
have to maintain local patches if they wanted to diverge from the chosen
default paths.

> If it is not optional, then it would be really good if it had a
> standard place to be installed. In the context of the common unix
> specification, the logical place is /usr/share/mercurial/contrib.

I doubt there is such a thing as a 'common UNIX specification', but
that's just the 10 years or so of my experience with FreeBSD vs. Solaris
vs. several GNU/Linux distributions.

> I don't want to dictate an answer here, but I would like to understand
> why installing something that was not properly installed before into
> the standard location is not a good solution on OpenBSD? Is there some
> other place that it should go?

Picking the 'standard place' is the hard part.  It tends to differ when
one switches OSes or even distributions of the same OS.



More information about the Mercurial-devel mailing list