Hi, Shawn Walker pÃÅ¡e v Ät 26. 06. 2008 v 08:28 -0500: > 2008/6/26 Milan Jurik <[EMAIL PROTECTED]>: > > Hi, > > > > Shawn Walker pÃÅ¡e v út 24. 06. 2008 v 22:37 -0500: > >> 2008/6/24 Moinak Ghosh <[EMAIL PROTECTED]>: > >> > On Wed, Jun 25, 2008 at 8:35 AM, Shawn Walker <[EMAIL PROTECTED]> wrote: > >> >> 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. > >> > >> Yes, an automated build facility would be great. I just wouldn't want > >> to see us setup a contrib repository where the only way to get things > >> into it was through the intervention of a build team member. Users > >> should just be able to contribute a package and necessary materials > >> and have it "show up" (perhaps after a quick manual approval by > >> someone). > >> > > > > It seems you are 10 years behind world. Welcome in world of automated > > build farms, like http://buildd.debian.org/ > > I'm well aware of automated build systems having setup some of them > myself. I just don't believe them to be a panacea. >
Why? Are they really complication? Did you maintain some packages on these systems? They are just wrappers around internal package build system. To simplify situation for maintainers and users. > > Contrib binary is dangerous idea. You can't review what was really send > > (easily). You are putting Opensolaris project under law and security > > pressure. And closing one of the benefit of open source - collaboration. > > Or make it hard, at least. > > Sorry but that's not a reasonable excuse to deny binary packages. They > are sometimes necessary. > Law and security? Isn't it? If somebody will submit mplayer, will people responsible to approve packages to contrib area investigate if that mplayer was built to not contain IP-protected parts? Do you think it's really easier to do this correctly based on binary-only packages? Or will they prohibite binaries based on "keywords"? I understand reasons for binary-only packages. For non-opensource providers. Like Acrobat Reader, Flash, nVidia drivers etc. No problem with them. But those are from very limited amount of sources which you (and mainly, infrastructure providers, like SMI in case of /contrib) trust. Law and security. Best regards, Milan
_______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
