Thanks Matt for your thoughtful response. Matt wrote: > Sometimes these build options are entirely valid things to be > configuring before building a binary. Sometimes it's just a method of > admitting you don't want to do the hard work of handling different > binary execution environments in your program. As you're probably also > familiar with, just because you have the source does not mean it will > work with your systems particular 'genome'.
Are you referring to different build environments (eg compiler version) or different binary execution environments (eg versions of binary shared libs installed)? The latter causes no more problem for source-based packages than for binary packages right? > With some "source based" linux distributions, upgrade of one particular > package will cause a cascade of upgrades. In some cases, this will > break a number of other things unintentionally (and without any way to > go back). This too can happen with either source-based or binary-based package management systems, but an ideal PMS (of either variety) will track dependencies and not allow such breakage. > > Additionally, the target CPU for a particular > > binary must be selected before the build - the > > performance penalty of using binaries targetted to a > > different CPU vary, but in some cases it is quite > > significant (such as on the Pentium 4). > > > Ah, but there are other solutions for that problem. Some of which > OpenSolaris already handles. Admittedly, it's more complex in the mixed > 32/64 bit area, but one can still get the capabilities one desires > without having to resort to everyone needing a compiler and the skills > to operate it. ... > OpenSolaris even uses this for libc, meaning applications can benefit > from different hardware capabilities without needing to be recompiled. > And the application developer didn't even need to know about it or > "configure" it. Yes, but the libc developer/packager needed to go to some effort to set it up. Most packages don't bother, right? In Gentoo Linux, the architecture needs to be configured once ever, and that applies to all packages built. That's no great burden on the admin, and is more complete than what you are suggesting. > It also means even old binaries created before the > existence of the new hardware capabilities can benefit from said > capabilities. That's cool, though only really useful if source code is not available. > >Distributing packages as binaries may be necessary > >for closed source software, but there's no need for > >such a limitation with open source software. > > > True, but you can, in some cases, run into other limitations. Just > because you have source, does not mean interdependencies do not exist. > Does the end user know how to handle this source package? Does the end > user know the right flags to throw at the config/makefile (GNU autoconf > doesn't get this right for me on most distros). This is exactly why one needs a (source-based) package management system which knows about dependencies and how to build each package, rather than getting the admin to compile stuff manually. In Gentoo, a one line command can build a package and all its dependencies. > Also, it's arguable that for some things (i.e. apps from ISVs that won't > provide source, device drivers source is not available for, etc.) you > will inhibit your own flexibility by expecting to be able to rebuild > dependencies from new source every time you upgrade one component. Sure, support binary-only packages as well (for closed-source software, as Gentoo does). This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
