Guido Berhoerster wrote: > I just became aware of the discussion on the contrib repo on > sw-porters-discuss through a cross-post, it does not seem to have > received attention there. The thread started here: > http://mail.opensolaris.org/pipermail/sw-porters-discuss/2008-November/000027.html > The proposal can be read here: > http://www.genunix.org/wiki/index.php/ContribRepo > > As this is about the future of OpenSolaris I'm posting my > thoughts on indiana-discuss. > With the current proposal the contrib repository becomes IMHO a > dumping ground for packages which have been built by someone > somehow. I consider a non-reproducible build, that is how, with > what patches, compiler options etc. the package was built, > problematic for a number of reasons:
I've heard repeatedly over time that barriers to entry are the excessive amounts of processes put in place around opensolaris.org contributions. While all of the things you mention are certainly good for the long-term management and health of the project, in the short term, the biggest problem we face isn't non-reproducible builds -- it's a lack of packages. For some of the same reasons that pkg(5) doesn't include a build system, I don't think it's reasonable to require that contributed packages have .spec files, since native ips package bundles ready for publishing should be permittable too. In addition, it also assumes that all build environments can be automated; that also isn't necessarily true. > * The first is security, if the package is built by some unknown > submitter, a review of the binary package only cannot easily > enforce quality and make sure no backdoors are injected etc. ...which source code and a reproducible build does not guarantee as the recent vulnerability in Debian that was there for years proved. > * Lastly, it is problematic with some FOSS licenses such as the > GPL which require a distributor of binary packages to make > available the _corresponding_ source, simply providing a URL to > external sources (as proposed) is not sufficient. For software that has licenses that require it, it obviously is, required. > The restrictions excluding Sun employees is just ridiculous > considering that they make up the vast majority of the community. > Do SFE maintainers who are employed by Sun have to find non-Sun > sponsors or are they completely excluded? Either way this cuts > severely into resources. Legal reasons as was cited previously. > Cutting red tape is certainly appreciated but going from one > extreme to the other does not seem to be an improvement to me. > Please look at proven procedures of how similar projects operate, > e.g. Redhat/Fedora, Debian non-main, Ubuntu universe, FreeBSD > Ports, pkgsrc. So far I haven't seen a reasonable compromise between either. As far as modeling the process on one of the distribution you've mentioned, I think a key flaw with that idea is that they're nanaging 15,000+ packages; we have 0. I think a better approach would be start lightweight and add processes as the number of packages grows. It's silly to me that we're spending more time developing processes than packages. -- Shawn Walker _______________________________________________ indiana-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
