> 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-discu > ss/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. >
writing a .spec file and running diff -u is not an excessive amount of process. It is a reasonable safeguard. It's not a week's worth of paperwork, the spec file is not too much different from just a package manifest, and the diffs take 30 seconds. > 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. > bad packages are worse than no 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. > if the build env. can't be automated then it's a bad package > > * 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. > which was found due to source, not due to someone getting bitten by it. > > * 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. and Package Build-Tron 5000 can turn 80% of random .tar.gz files in to packages in minutes, it also makes julienne fries. distribute a .spec-ish file stub that does "tar -zxvf $FILENAME ./configure; make; make install" as an automated check box and most random sourceforge junk will just work. if things need to be made different ( different cflags, etc ), specify them on the "upload package" page > I think a better approach would be start lightweight > and add processes > as the number of packages grows. short-selling your future is a bad idea all around > It's silly to me that we're spending more time > developing processes than > packages. the two aren't mutually exclusive. -- This message posted from opensolaris.org
