Providing source code along with binaries - was Re: [GRASS-dev] WinGRASS-6.3.0RC5 Self Installer

Moritz Lennert mlennert at
Wed Mar 26 04:53:06 EDT 2008

On 25/03/08 16:42, Markus Neteler wrote:
> (cc PSC,
>  thread:
> )
> On Tue, Mar 25, 2008 at 1:18 PM, Moritz Lennert
> <mlennert at> wrote:
>> On 25/03/08 10:13, Markus Neteler wrote:
>>  > Moritz Lennert wrote: ...
> ...
>>  >> Everything is available at
>>  >>
>>  >> including the version of the GRASS sources you used (don't think
>>  >> this is necessary, but just to be complete). All packages are
>>  >> available individually, and there also is a wingrass_sources.tar
>>  >> which contains them all.
>>  >>
>>  >> Maybe Markus can just get the tar and put it on the download site
>>  >> next to the installer ?
>>  >
>>  > you mean: wingrass_sources.tar        13-Mar-2008 11:48        45M ?
>>  >

Note that a big chunk of that is the GRASS source which is already on 
the site, so it doesn't need to be replicated. Just took that out and 
now we are down to 29M.

>>  > I am not sure if we should really store that on the OSGeo server.
>>  > Then we have to do the same also for all the other binaries and fill
>>  >  up the server space with overhead. If you insist, I suggest to
>>  > discuss this on the GRASS-PSC list.
>>  What do you mean by "all the other binaries" ?
> Perhaps Linux, Mac, Ultrix, DEC, ...? binaries require different
> source packages. So we would accumulate a lot once we start to
> provide more binaries (as soon as the OSGeo buildbot is open for
> us).

Well, strictly speaking GRASS as a team only has to cover those binaries 
which are published on the GRASS site, so the MacOSX binaries are the 
responsibility of the respective maintainers. Debian and Ubuntu packages 
already provide sources, I suppose that Gentoo does so also by 
definition, SUSE does as well, don't know about Mandriva.

This leaves us with the "Generic" GNU/Linux binaries which lead to the 
same page as the Fedora Core link on the download page (why is this so - 
I wouldn't consider Fedora binaries as being generic ?). Both of these 
seem quite out of date...and only the Fedora directories provide other 
binaries than GRASS (are they still needed on this server ?).

So, unless we think that Fedora binaries of other dependencies of GRASS 
should be hosted on the server, the only binary package where this is an 
issue is the MS Windows installer...

>>  > We could store the hard-to-get sources, but why host PROJ4, GDAL and
>>  >  such?
>>  Here is what Glynn wrote a bit earlier in this thread:
>>> Please note that, if you provide binaries which are covered by the
>>  > GPL, you must provide the corresponding source code for download
>>  > *from the same place*. It isn't sufficient to point to the source on
>>  > a different site.
> Just curious why this didn't came up earlier (GPL change in 1999).
> ?
>>From the same place would cover
> ?
>>  > Alternatively, you can provide a written offer to supply the source
>>  > code upon request, but that means that you have to keep those exact
>>  > versions of the source code handy for the next 3 years (the website
>>  > where you obtained it may cease to provide it when a new version is
>>  > released).
> If we/us/PSC decides that we want to provide all (!) the needed source
> code packages, we need a systematic approach. I still don't think that
> we should just throw stuff into the mswindows/ directory.

No, if we use the same sources for different platform binaries then it 
should be enough to host them once, including possible platform-specific 
diffs. But at the current state, I don't think we are in that situation, 
except for the outdated Fedora binaries.

What exactly is the issue: is it limited disk space on the OSGeo servers ?


More information about the grass-dev mailing list