Re: Redistributing Strawberry Perl

[email protected] (kmx) Mon, 27 Oct 2014 10:32:22 +0100
Newsgroups perl.win32.vanilla
Message-ID <[email protected]>
On 24.10.2014 0:50, Daniel Kasak wrote:
> Hi all.
>
> I've managed ( thanks to a developer I hired ) to build Gtk3 libraries 
> and Perl bindings that work with Strawberry Perl. I'm now planning on 
> maintaining the Gtk3 and binding stuff, and hosting Windows binaries. I 
> have a reasonable idea of the legal requirements involved in 
> redistributing open-source stuff, but I'm basically looking for people's 
> blessing to distribute ( at this point ) a large package that includes 
> everything, and call it something 
> like: strawberry-5.20.1-gtk-3.14.3-v1.0.zip. Does anyone have objections 
> to me using the 'strawberry' name? Or any other objections?

It is absolutely fine to redistribute strawberry perl providing that your 
project comply with licenses of individual packages included in strawberry 
perl. Strawberry perl itself does not introduce any restrictions regarding 
redistributing/repackaging.

As for using "strawberry" in the name of your alternative/experimental perl 
distribution I am concerned just about end users being confused. Perhaps 
Adam Kennedy who is in charge of strawberryperl.com domain might have some 
opinion.

The other option for you might be to join strawberry perl project and make 
your gtk3 distribution available from 
http://strawberryperl.com/releases.html as we provide "PortableZIP edition 
+ extra PDL related libs" (which is basically strawberry perl + bunch of 
math related external libraries).


>
> In the medium term, I hope to be able to break things out into individual 
> packages that people can install on top of an existing Strawberry Perl 
> installation ( or maybe even have this work rolled into Stawberry Perl ), 
> but at this point, I have one large installation directory and a 
> repeatable process to build things.
>
> On the topic of packaging things ... if anyone knows an easy solution for 
> making these individual packages under mingw & msys, that will help a 
> lot. I had a look at the tools used in the build of Camelbox ( another 
> such project, but targeting Gtk2 ), and from what I could tell, the 
> process was basically doing a comparison of the filesystem before & after 
> installing each package to determine what files should be added to a 
> package. Is this the only way of doing this? If it is, I guess I'll go 
> down that path too ...

I have uploaded to github - https://github.com/StrawberryPerl/build-extlibs 
- our scripts we use for building external libraries bundled with 
strawberry perl. They are very simple and not much clever (as you guess 
doing a comparison of the file system before & after installing each 
package) but they work.

Maybe you will find interesting https://github.com/Alexpux/MINGW-packages - 
which is much more sophisticated (and also includes scripts+patches to 
build gtk3).

--
kmx