2008/6/25 Moinak Ghosh <[EMAIL PROTECTED]>: > On Wed, Jun 25, 2008 at 6:47 PM, Shawn Walker <[EMAIL PROTECTED]> wrote: >> 2008/6/24 Nicolas Williams <[EMAIL PROTECTED]>: >>> On Tue, Jun 24, 2008 at 11:25:25PM -0500, Nicolas Williams wrote: >>>> On Tue, Jun 24, 2008 at 11:08:57PM -0500, Shawn Walker wrote: >>>> > > The alternative, IMO, is the slightly more heavyweight trusted >>>> > > maintainer model. >>>> > >>>> > I believe a mixed model is more appropriate. >>>> > >>>> > In short, I'm just going to have to disagree with you on requiring >>>> > things to be buildable to be contributable. >>>> >>>> Let users decide whether they want to install stuff from /contrib that >>>> has no source to go with it (and/or which has not been rebuilt by >>>> others). >>> >>> Or which has even been rebuilt and signed by others. Without a >>> careful source code audit you may have no clue as to whether you can >>> trust the binaries. Again, if noone will trust /contrib, so noone >>> will use it, then there will be no point to hosting it. >> >> Right, which comes back to the package maintainer. There will be times >> when no source code for certain materials is no available (firmware, >> notably) for drivers, etc. >> >> It's all about who you trust. >> >> Even though many community repositories do not provide public build >> recipes and exact source to reproduce their packages, they have a >> trustworthy reputation and thus individuals have no problems using >> packages from them. >> >> Trying to enforce a universal build system on all packages (requiring >> it as part of policy) is doomed to failure. > > Spec files are just build recipes. They do not enforce a particular build > system. For the heck of it I can write a "small" Spec file to build the ON > tree and generate packages and it will still be using the ON build system. > > Specs are nothing but a recipe normally intended for building RPMs. Is > there any software for which we cannot have a Spec and thus cannot > have an RPM package ?
I'm familiar with specfiles having written many of them for RedHat systems. However, I think the main problem I see is that package boundaries are != build boundaries. For example, OpenSolaris itself has packages that contain files from multiple consolidations. I really have nothing more to say than I don't think this should be a requirement. For some of the same reasons that pkg doesn't provide a standard build system, I don't believe we should require one for contributed packages. -- Shawn Walker _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
