On Wed, 9 Jul 2008 00:09:27 -0400 "Fredrich Maney" <[EMAIL PROTECTED]> wrote: > > "Yes" on #3 isn't so bad. I think there needs to be a clear > > distinction between "this software is maintained, tested, built and > > supplied by the vendor" vs. "this is a vendor-blessed build of third > > party software, but it is *not* maintained, tested or supported by the > > vendor", including having them on separate update cycles. Having two > > separate repositories makes those things easy to do, but it's not > > clear it's impossible with just one repository. > One nit here, the distinction is between "software that is built, > maintained, tested, supported and supplied by the vendor" and > "software that is not built, maintained, tested, supported and > supplied by the vendor". If you want to further delineate the second > group into "3rd part software blessed by the vendor" and 3rd party > software not blessed by the vendor", that's fine, but it is a > different delineation.
This may be a different delineation, but it's also the difference between a user having simple access to the tens of thousands of FOSS applications available and a user cursing your system in frustration every time they want something that's not part of the "software that is built, maintained, tested, supported and supplied by the vendor." Linux distros ~10 years ago didn't provide much software in that category. If you wanted some non-trivial package, you wound up hunting through multiple repositories trying to find all the appropriate parts built against the proper other packages to actually install what you needed. Lately, those distros include pretty much everything that's popular (though from what I can tell, they are still an order of magnitude behind the groups that did it the way I suggest here), so it's only people wanting obscure or cutting-edge packages or working with older distributions for political reasons that wind up in that particularly painful place. ON is in the early stages of this now, with three or four software repositories maintained by multiple groups (and at least one distribution that's apparently trying to include everything modern Linux distros include). Since they each use a different base directory, they can coexist, so it's not as bad as Linux was or is. However, if I want something that's not in either of them, but has requirements some of which are in one and some in another, I'm pretty much wedged (the one time it's happened so far it wasn't as bad as it typically is on Linux, though). By having a repository of such software that is a "vendor blessed build" - even though the vendor may do nothing more than make sure it builds properly before checking it in and making it available - you provide a common base for people building FOSS software to work from. So if I want to build a package that needs foo, bar and baz each of which depend on one or both of gort and glub, if I find foo, bar and baz in the "vendor blessed build", I know they will all use the gort and glub from the same repository, and hence work together. There's some other properties I think such a repository needs to be really sucessful, but it's existence has to be the first step. FWIW, the most interesting such archive for this audience might be the pkgsrc archive from NetBSD. It's relatively small - maybe seven thousand packages max for any architecture, but it's also already been ported to solaris, with some four thousand packages having survived the move to solaris on x86. <mike -- Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org _______________________________________________ opensolaris-discuss mailing list [email protected]
