Re: Experimental Win32 package from trunk/r13021

On Tue, 15 Feb 2005 17:56:31 -0500, Toby Johnson <toby@etjohnson.us> wrote:

> Yes, that's what I'm proposing.

Yeah, I agree with you here. Great idea.

> I think they should go in svn-win32-1.2.0/perl/bin for the simple fact
> that they're perl binaries, not general Subversion binaries.

I think most people just does:

  C:\> unzip svn-win32-1.2.0*.zip

rather than taking the trouble of unzipping the Perl bindings into
C:\perl, the Python bindings on C:\Python\lib\site-packages, etc.

> Everything
> that the perl bindings need to work should be in one place, not
> scattered throughout the package. End users could move them wherever
> they want.

As I see it, you're proposing a directory structure based on the idea
of puting the perl bindings on some other place (even if it's a
reasonable place, which of course is), while I'm more onto making the
binding "Subversion-distribution-centered", so to speak. Neither one
is more "scattered" than the other. I don't like much the perl/bin
idea just because, as I've said, I try not to put things into
perl/site/ withouth PPM's knowledge. "ppm query" is non-useful for
such packages.

> Also, is it possible to install from a .PPD without first placing it in
> a repository? (PPM repository, that is).

Yes. With ExtUtils::MakeMaker and make_ppm.bat you can build a .ZIP
that contains three things: a README, a .PPD file and the archive that
contains the real files (usually a .tar.gz archive). You can just do:

  C:\temp> unzip svn-win32-1.2.0.zip
  C:\temp> ppm install svn-win32-1.2.0.ppd

et voilą. Of course, someone has to build the PPM package beforehand
(but it isn't difficult).

> Alternatively, are there any
> "third-party" PPM repositories that might accept a complete SVN package?

Not sure, but perhaps the Winnipeg folk
(http://theoryx5.uwinnipeg.ca/cgi-bin/ppmserver?urn:/PPMServer58)
would be willing. They already host the mod_perl binaries for
ActivePerl and quite a few other packages.

> (Or... does ActiveState accept contributions from third parties?) If

Not sure either.

All in all, the perl/site/lib/SVN and perl/site/lib/auto/SVN dirs are
the really important issue here (otherwise you end having to move
quite a few things around); adopting that structure will be a net
gain. I'm not too worried of being forced to move the SWIG .DLLs to
bin/ from perl/bin.

-- 
                    /L/e/k/t/u
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org