>>>>> On Sun, 14 Jul 2013 07:00:14 -0600, Matthew Flatt <mfl...@cs.utah.edu>
>>>>> said:
>> At Sun, 14 Jul 2013 02:54:06 +0200, Juan Francisco Cantero Hurtado wrote:
>> > On 07/13/13 20:56, Matthew Flatt wrote:
>> > [...] > > ** Downloading release installers from PLT
>> > >
>> > > The "www.racket-lang.org" site's big blue button will provide the
>> same > > installers that it does now, at least by default. That is, the
>> content > > provided by the installer --- DrRacket, teaching languages,
>> etc. --- > > will be pretty much the same as now.
>> > >
>> >
>> > Will be also available a big tarball with the source and all
>> batteries > included, like the actual "unix source"?. Will be possible
>> to compile a > full distro of racket with the usual "configure && make
>> && make install"?
Matthew> To clarify (because I now realize this may not have been apparent
Matthew> to others), you have in mind delivering Racket's main
Matthew> distribution as an OpenBSD port, right?
Just to add myself to the conversation, I am package maintainer for openSUSE
and racket has been in the opensuse repos for some time now. Also with the
next release it will also be part of the main opensuse distribution.
Currently, the package is built for openSUSE 12.2 12.3 and Factory versions
Matthew> At Sun, 14 Jul 2013 06:00:17 -0600, Matthew Flatt wrote:
>> This was not been part of the plan. Now that you ask, though, I see how
>> it makes sense to package the core source together with package sources
>> for a given set of packages --- including the "main-distribution"
>> package, for a site that distributes "main-distribution" installers.
Matthew> Longer term, I think that OS-level packages/ports should probably
Matthew> reflect a minimal Racket installation, and then further Racket
Matthew> packages would be installed via the Racket package system.
Well, I would argue the other way around, as the whole package system would
have been prepared for the distribution in mind, for example I build the
package with shared-libraries, and avoding any static library, in addition to
not to use bundled software ie. libffi.
This makes my life as the maintainer of the package easier as any possible
bug/security fix would be easier.
Having said that the idea sounds more like the Emacs elpa system, and the user
has the option to either download the distro provided packages or elpa
versions. So in a effect racket goes the similar way.
Matthew> But I can also see how a "main Racket distribution" package/port
Matthew> that resides completely within the OS's system could also make
Matthew> sense, especially in the short term. A core+package source
Matthew> tarball should make that easier.
That would be make the package maintaining easy.
Thanks
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
