On Wed, Jul 9, 2008 at 1:12 AM, Mike Meyer <[EMAIL PROTECTED]> wrote: > 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."
I think we are largely on the same page. There are several ways to look at these packages, and hence to organize them. I look at it this way, there are two types of packages: OS vendor supplied, and 3rd party supplied. You seem to be seeing three types: OS vendor developed/maintained/supplied, OS vendor blessed/supplied 3rd party, and 3rd party developed/maintained/supplied. [...] > 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). That is a problem for the application provider to resolve, not the OS vendor. If a 3rd party developer wants to port their application to a given OS, then they need to do the legwork of making it work within an existing vendor or 3rd party provided repository, or they need to provide all the dependencies themself. If you are wanting to port application to OS then the onus of doing that legwork falls on you. That has always been the case and I don't see a problem with that paradigm. > 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. I think it has been proven time and again that it doesn't make much sense for any vendor to be in the business of providing 3rd party applications - they end up catching the blame for the problems with that application and being forced to develop/support in order to minimize that user frustration. That is one of the main reasons we end up with code forks in FOSS. A better solution for Sun is to support a 3rd party organization (like Sunfreeware, Blastwave or OpenSolaris) taking on that role. They can provide support, funding and expertise to that/those organization(s) in exchange for some degree of control/guidance to insure that everything plays well together and follows the same general direction. [...] fpsm _______________________________________________ opensolaris-discuss mailing list [email protected]
