Bug#330824: I dont believe this bug was acted on properly

[Peter Samuelson]

> Back-handed passive-agressive statements are not productive, but
> instead provoke angry responses, but lets not get angry.

Apologies for the tone.  I really do not know why I got so worked up
there.

> > Many of the files there are usable in situ.  Moved to the examples
> > directory, they wouldn't be (thanks to Policy about gzip).

> This makes a lot of sense.  I was not aware that the example files
> are actually usable in situ.

The example config files are not - you have to rename and modify them,
which is not something we should encourage people to do in /usr/share
(or /usr/lib) - so I'm actually not very comfortable with the whole
situation.  But the alternative, moving them (and presumably the
respective scripts) to doc/*/examples - well, that splits up the
scripts usable in situ from the ones that must be [copied elsewhere
and] configured.  So two sets of scripts in two different places for
the same basic purpose.

Still pondering.  A happy medium might be to move the scripts + configs
we are talking about, and stick a README in /usr/share/svn/hook-scripts
pointing to doc/svn/examples/h-s/ for more.  Your thoughts on this,
despite the tone of my earlier email, are welcome.


> >   The other script affected is /usr/lib/subversion/hot-backup.py,
> >   which has now moved into /usr/share/doc/subversion/examples.  It
> >   was never a supported executable (or it would live in /usr/bin).
> >   It is also no longer needed, because "svnadmin hotcopy" now
> >   includes the same functionality.  Please use "svnadmin hotcopy"
> >   instead.

> Seems odd to include this at all if it is unsupported.  Additionally,
> the examples/ directory seems like a strange place to put scripts,
> but nevertheless, thats up to you.

I've seen plenty of example scripts in doc/*/examples/ directories.
This particular one, I dunno, just looked out of place in
/usr/share/svn - traditionally executables in /usr/lib/foo and
/usr/share/foo are ones used by foo itself in some way.  This one's
different, it's intended to be run by an admin or script, the sort of
thing one would have in /usr/bin or /usr/local/bin.

I'm just not comfortable putting extra stuff in /usr/bin until I've
convinced myself it can be supported long-term.  /usr/bin is a
sufficiently "public API" that I feel it's kind of bad to take anything
away from it, once shipped.

We *have* been getting requests to ship some of upstream's contrib/
scripts.  I'm still not sure how to handle that - hard to know what we
can properly support when upstream refuses to consider the scripts
anything more than "contrib".  It may be useful to create a
subversion-contrib package for this purpose and thus distance ourselves
a bit from the usual implication that this stuff is fully supported and
that no binaries will ever disappear.  If we do this, the two scripts
now in /usr/share/doc/subversion/examples/ can go in that package.

Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-subversion-maintainers/attachments/20051105/38f427b5/attachment.pgp