On Wed, Jun 25, 2008 at 8:35 AM, Shawn Walker <[EMAIL PROTECTED]> wrote: > 2008/6/24 Moinak Ghosh <[EMAIL PROTECTED]>: >> On Wed, Jun 25, 2008 at 6:05 AM, Shawn Walker <[EMAIL PROTECTED]> wrote: >>> 2008/6/24 Guido Berhoerster <[EMAIL PROTECTED]>: >>>> Shawn Walker wrote: >>>>> >>>>> 2008/6/24 Chris Ridd <[EMAIL PROTECTED]>: >>>>>> >>>>>> On 19 Jun 2008, at 08:32, Venky wrote: >>>>>> >>>>>>> I find third-party contributors directly submitting binaries a scary >>>>>>> prospect. The best option, IMO, would be to have them submit >>>>>>> patches and build recipes (which are much more easily vetted) and >>>>>>> have the actual build carried out by the /contrib project. Going >>>>>>> the SFE way would seem to be the best option for this. >>>>>> >>>>>> Would requiring that all ELF binaries be signed (noting the recent >>>>>> elfsign thread) mitigate your concerns? Obviously they only tell you >>>>>> who provided the bad binaries in the first place, and it wouldn't help >>>>>> at all with dangerous scripts. >>>>>> >>>>>> Having a build recipe seems safer though. This would make the contrib >>>>>> repository a bit like the ports systems on other OSes (eg FreeBSD, >>>>>> MacPorts, Gentoo, etc.) >>>>> >>>>> As long as there is an audit trail, I think it is perfectly acceptable >>>>> to allow direct third-party contributions. >>>>> >>>>> Whether published packages should get "approved" by a contrib project >>>>> member before being available is another story. >>>>> >>>>> I do not believe that contrib project members should have to be >>>>> responsible for building everything (again). >>>> >>>> Firstly, it generates transparency, nothing beats taking a quick look at >>>> http://www.freebsd.org/cgi/cvsweb.cgi/ports/ or >>>> http://pkgbuild.svn.sourceforge.net/viewvc/pkgbuild/spec-files-extra/trunk/ >>>> etc. how a package is built and with what patches. >>> >>> You can still have transparency without making so that one group of >>> people has to rebuild everything. >>> >>>> Secondly, it allows for easy customization by modifying a build recipe. >>> >>> Again, you don't have to operating things that way to achieve the same >>> results. >>> >>> And in some cases, no source code may be available. >>> >>>>> I don't believe such a model will scale very well. >>>> >>>> Look at the mentioned FreeBSD Ports (18700) or NetBSD Pkgsrc (7500), in >>>> fact >>>> it does scale very well. >>> >>> Sorry, but I just don't agree. >> >> Allow binaries but also require submission of source, otherwise IMHO >> the model is broken. Simply submitting binaries does not result in a >> reproducible build, does not allow others in the community to participate >> in fixing/enhancing stuff in the software. It is a rather limited model and >> not in the spirit of opensource. Binaries can get stale given the rapid >> pace of change. Not having the ability to rebuild and do bulk-builds is >> quite a handicap. Now it is not really necessary that the contrib folks >> themselves do builds all the time. There are enough folks in the >> community for doing that. It should be mandated that binary submissions >> be accompanied by a corresponding submission of a Spec file into SFE >> or a contribution into SFW gate if you will. >> You can't have transparency without mandating contributions in source >> form along with binaries - does not mean that contrib team members >> have to rebuild every package. > > That's mainly what I'm getting at; just put a much better way. > > It's perfectly fine, in my view, to require that the materials > necessary to rebuild the package be provided (even if those materials > are primarly binaries in some cases). > > There's no reason to require duplicated efforts to have packages in a > repository.
Ok. A suggestion. For the longer run I think it is pertinent to evolve tooling/infrastructure for automated builds of package submissions possibly using the Test Farm resources. Essentially the submission of a package triggers the scheduling of a future build of the source recipe to verify correctness with a mechanism to get the results back to the contributor. Human intervention should not be necessary. Regards, Moinak. > > -- > Shawn Walker > _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
