Hi, I'm sorry for late reaction, a bit busy with other things, not reading pkg-discuss too much.
V čt, 26. 06. 2008 v 17:46, Kohsuke Kawaguchi píše: > 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. If integrated in repository, why not as build dependency? > Sometimes you need a fairly minor build tool like Gradle. Gradle? www.gradle.org? Why can't it be integrated in repository and can't that particular software depend on it? > Sometimes you need some jars that are not redistributable as a > compile-time dependency. It's that sort of things. > This thing I understand. But not sure if such type of deliverables should be part of main repository. As I said, binary-only repository brings: a) security concerns b) law concerns and decrease possibility of community cooperation > > > 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 know how hard is to create good and correct "rebuildable" package. I'm doing such things very frequently. And I still see huge benefit for significant preference of source-submitted packages. Yes, there are cases where it's impossible to do it. But why to make it by default? > > >> 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. > Are you sure that the infrastructure provider is not vunerable against patent lawsuits? Best regards, Milan _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
