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 readonlymode 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 forthem 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.
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.
I know this sounds very scary to many of you, but it's been working and I am not aware of any security incidents.
Reasonable people can disagree about why this works, but I think one key reason is the naming of the package. Your package would have to be prefixed with your reverse domain name (like "com.sun" in our case), and you do have to prove that you are the rightful owner of the domain when you submit your package.
So a random Joe cannot publish a package like "org.apache.ant". And therefore consumer of packages could trust that the package "org.apache.ant" came from Apache.
This also makes name disambiguation automatic. Two people can independently come up with the "foo" project and their package names won't collide.
Packages built locally by developers on assorted laptops/etc in various state of install means some of them will run on baseline 2008.05 and other won't. (And some will run nowhere except in the submitters own machine - people do get creative installing things with their main work desktops.) If the goal is to have lots of applications useful to everyone, as opposed to just lots of packages, they should get built on baselined RE machines. Certainly by an automated process, as I see discussed a little later in the thread, since centralized manual interaction doesn't scale.
-- 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
