Milan Jurik wrote:
Hi,Kohsuke Kawaguchi p????e v st 25. 06. 2008 v 18:54 -0700:Jyri Virkki wrote: > Stephen Hahn wrote: >>>> >> So, to answer these questions, the model David and I have been toying>> with is a "contrib" repository, with the largest component being >> binary packages from the recipes in the spec-files-extra or the F/OSS >> package base projects > [...]> >> 3. Either send us the URL to your private depot (running in readonly >> mode if public!), or use pkgrecv and GNU tar to collect your >> package in transaction form--and send us a URL to that file. > > Having anyone and everyone contribute pre-built binary packages is a> bad idea. It's ok for testing/experimenting but not for formally > published packages.> > Published packages need to be built on a known-standardized (on the> lowest common denominator supported) Release Engineering machine for> them to reliably be useful for everyone else. All the major distros seem to agree on this view, but this does increase the bar. For example, our Java projects (like GlassFish) always have very hard time getting into the Ubuntu repository because the Java projects build very differently. This pain shall not be under-estimated.So is support missing in build tools (provided by automated build process) to simplify the build process? If yes, can't it be included? Or is it just bad design of internal build process, which needs manual interventions?
I don't think it's because of a bad build process. It's just the reality. For example, sometimes you need a specific version of a build tool. Sometimes you need a fairly minor build tool like Gradle. Sometimes you need some jars that are not redistributable as a compile-time dependency. It's that sort of things.
I believe that Debian already contains a lot of jars, including very complex Java projects.
Yes, but it still has a problem with any projects built with Maven (and Maven is perhaps the 2nd most widely-used build system), and this includes GlassFish. So that's why I said it's painful.
I'd like to present an interesting case study --- Maven repository.Maven repository is a repository of binary jar files. It contains several 10,000s of jars from all over the Java eco-system. Now, these jar files are not built by any standard process nor by any official release engineering of any sort. Process-wise, you can submit any binary, with or without source code, and it'll be accepted.Including those which can contain patented code? Who is providing the infrastructure?
IANAL, but patent and redistributability are orthogonal. The infrastructure (which is in this case just a web server with a bunch of jars) is provided by Ibiblio, I think.
-- Kohsuke Kawaguchi Sun Microsystems [EMAIL PROTECTED]
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
