Your source distribution will always be your primary distribution, and from that it should be possible to build any of the binary distributions. This is where you would typically have things such as "install.sh" scripts. Advanced users are your audience.
>From this package, it should be possible to build your binary packages. And your binary packages are what your regular users are going to want to use, in all likelihood. Source packages (properly: release artefacts) are the only thing you vote on, because it's the only official release artefact you produce. From these official artefacts, the project may provide the binary artefacts for convenience. This may or may not be on ASF hardware, but it is obviously preferred. And you can link to these binary artefacts from the homepage, etc, as long as the distinction is made clear. Now, with things like debs, you'll run into a problem. Depends what we want to do here. Do we want to provide a single deb file? If so, there should be no problem setting up a "/binaries" directory under your "/dist" directory, and just plonking files in there, and linking to them. This will work perfectly fine with the mirrors. But will our users want to be able to update /etc/apt/sources.list? If so, you're looking at creating an APT repository under "/dist". (Which is nothing more than a carefully organised tree of files.) However, we run into a problem here. This wont work with the mirrors. (Unless you specifically direct users to point their sources.list at a specific mirror, which will be fraught with problems.) The other option will be to point sources.list to the APT repository as it lives under "/dist". But this may generate a lot of traffic. I have not spoken to infra about this, so I don't know how they feel. Could always set up a new box, dedicated to hosting binary repositories? (Whether that is ASF hardware, of donated.) I presume something like this exists in any case for Java stuff? (I don't have too much experience with Java packaging, sorry.) On Tue, Sep 11, 2012 at 7:23 PM, Chip Childers <chip.child...@sungard.com>wrote: > On Tue, Sep 11, 2012 at 11:45 AM, David Nalley <da...@gnsa.us> wrote: > > On Tue, Sep 11, 2012 at 8:23 AM, Wido den Hollander <w...@widodh.nl> > wrote: > >> On 09/11/2012 12:16 PM, Suresh Sadhu wrote: > >>> > >>> HI All, > >>> > >>> Installer fail to read the cloud packages and MS installation on > Ubuntu > >>> 12.04 was not successful(No packages were installed) Raised a blocker > bug. > >>> Please find the issue details in the below mentioned issue: > >>> > >> > >> I'd like to bring this up again, do we REALLY want this install.sh > script? > > > > > > This really deserves its own thread, because it won't receive the > > attention it deserves in the original thread. > > > > I talked with infra about this a few weeks back, and while they said > > they really wanted downstreams to package, they weren't vehemently > > opposed to use creating our own repo, but we'd have to figure out how > > to make it work with the mirror system. > > > > Personally - the packages as they exist are great for people doing a > > first, small scale install, but it doesn't scale. While I am not > > necessarily opposed to the installer, I also recognize the problems > > from a real world deployment perspective. > > > > However, there is an impact, at a minimum all of our documentation > > will need rewriting, so personally, I'd prefer that for 4.0.0 - that > > we do repos if we can figure it out in time, and keep the installer as > > an option as well. > > > > --David > > > > Thanks for starting the thread David (you beat me to it). > > My thoughts: > > Having downstream packagers is the way to go for official package > distribution of the software for each OS. However, I would like us to > include the RPMs and DEB packages that we agreed to previously (Ubuntu > 12.04 and RHEL/CentOS 6.2 and 6.3) as a binary distro via ASF > infrastructure. I'd also like us to include this install script > (functionally working for its intended purpose) with the RPMs. My > thinking is similar to David's, in that it's easy to get started with > that model. > > I don't believe that the tarball that includes packages and the > install script hurts more advanced installers at all, since we can > have other methods of getting the packages (perhaps ALSO hosting the > packages on public repos that use the ASF mirrors, or even on repos > that aren't on ASF infrastructure). > > Just my thoughts... looking for others to chime in. > > -chip > -- NS
