[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

IGNORE PREVIOUS:Contribs/tools/Mandrake subpackages oh my - REPLY-TO set correctly here.

From: Files <files_at_poetryunlimited.com>
Date: 2003-10-25 07:07:31 CEST

Sorry - I didn't successfully set the reply-to last time. I apologize

Please make sure you reply directly to me unless the COMMITERS say it's ok
to reply to this in the list.


Ok. I almost have everything where I want it to be in the Mandrake RPM
build set. Where it *just works*.

Then I notice that the files I expect to be packaged, all of a sudden aren't.

Where have they moved to? /contribs.

Are they packaged in any RPM build set? Not that I can see.

Are there special commands to build them? Not sure. I know
svn_load_dirs.pl builds on configure from what I can see.

What about svn_push and the rest? They seem to require a

make contrib

Did I get that right?

And lastly, what is the proper install location for files such as
svn_load_dirs.pl and so on?

It would be really nice if the authors of the contribs could step up and
explain where they see their tools installed.

Whether it's in /usr/lib/subversion/tools, etc etc etc.

You get my drift. Without knowing where they belong, I'm finding it hard
to figure out where they should go.

I know where they used to be. I can rewind back to that. But rather than
be tied down to legacy decisions, I'd like to offer the authors a chance
to expound on where these files should end up.

Similarly, there are tools like cvs2svn in the /usr/lib/subversion/tools

Where should they go? Should they have their own package? How do the
authors of the main subversion package feel about that? Should those
commands be symlinked to the main /usr/bin?

A little more exposition is necessary I think.

Mandrake users by and large, unless they buy the Powerpack or the Server
edition, really aren't all that interested in rooting around w/ a
roto-rooter to figure out how something should happen. It should just be

Then again, cvs2svn - only used very infrequently, so maybe it's not that
important to symlink it.

Just so everyone is clear on the one's I need comments on, I will attach
them in a .bz2, but when you reply, please only include the relevant

They include entries in /contrib, /notes, /tools, and /www.

What I need to know

1. What to include.
2. What to omit.
3. Where to put it (directory structure).
4. What sub-package it belongs in (I inherited these packages mostly), or
if it belongs in a new one:
a. base (svnserve, svnversion, basic shared libraries, HACKING etc, and
man pages)
b. repos (svnadmin, svndumpfilter, svnlook, and related libs)
c. client-common (svn and related libs)
d. client-dav (ra_dav)
e. client-local (ra_local)
f. client-svn (ra_svn)
g. devel (.a, .h)
h. raw-doc (uncompiled docs - if docbook not present)
i. server (apache modules and conf files)
j. doc (compiled docs html and pdf)
k. tools (/tools directory contents)
l. javahl (jar file)
Specify files ONLY if directories are not sufficiently granular.

And please please please please please - reply DIRECTLY to me.

I will set the REPLY-TO on my email so that it comes right back to me.

Do NOT overload the list by replying here, unless the COMMITERS say it's ok.


Personally, I keep thinking that the server subpackage should be called
apache2 or httpd (subversion-apache2, or subversion-httpd); that the base
subpackage should be called subversion-server, or just subversion; that
the svnserve should be in its own subpackage possibly; and that the tools
subpackage should be called subversion-utils.

And lastly, that the man pages should be included in the subpackage that
has the program the man page refers to.

If anyone wants to comment on the subpackages, or thinks we need different
subpackages, feel free to speak up. I think they make sense for the most
part. Just certain things aren't immediately obvious.

I will take all opinions into consideration and try to come up w/
something that makes sense.


Thank you for your patience.

I look forward to the clarification.

I will compile it all in a single document and submit it to the list after
I receive all entries for any other package maintainers.

If on the other hand the COMMITTERS say it's ok to reply in the list, feel
free to follow their lead.

Shamim Islam

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Received on Sat Oct 25 07:08:05 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.