I would submit that in the desktop realm, you would be correct. However, in my experience in the server realm, custom builds are pretty common. For example, until very recently (like the last 2 years), I've rarely seen anyone run the Sun provided BIND, Sendmail or Apache daemons on production servers and most have made significant changes to what was installed and where it went. Partly that is due to fact that most (corporate) servers are required to meet corporate standard builds that span operating systems and OS versions. It is also due to the fact that many servers are still (rightly in my mind) built with minimized configurations that do not include most of the fluff needed to run the latest gee-whiz GUI based management tools - I should not have to run a web server and java just so that I can use SMC to manage a DNS or mail server.
fpsm On Wed, Oct 22, 2008 at 5:28 PM, Shawn Walker <[EMAIL PROTECTED]> wrote: > Mike Meyer wrote: >> On Wed, 22 Oct 2008 11:49:36 PDT "Richard L. Hamilton" <[EMAIL PROTECTED]> >> wrote: >> >>>> I'd much rather see a ports type implementation than >>>> an rpm >>>> implementation - particularly if it includes the >>>> sources. >>> Sources available? Darn right - some of the licenses require that, too. >> >> Sources is one thing. Being able to build it is quite another. >> >>> Build from source as the normal method of installation? That, I think is >>> too slow for most people (who would have trouble spelling "C", and wouldn't >>> be interested anyway). >> >> True. And most people don't care much about having lots of unused code >> around or the security implications of doing that, either. So things >> like apt & rpm make them happy. >> >> However, the various ports systems demonstrate two things: >> >> 1) Given a good package manager that handles dependencies properly, >> you can provide binaries packages that let the user configure only >> what they need (assuming, of course, that this is reasonable for >> the software in question). >> >> 2) If you provide a mechanism that lets people set compile-time >> configuration options, package developers will provide them, and >> end users will put up with compiling from source to take advantage >> of them. >> >> Both of these are important. The first because, as you say, compiling >> is to slow for most people and most packages. The second because it's >> more important to get critical packages configured *right* than it is >> to get them installed immediately. >> >> Having a system that makes rebuilding from sources as simple as >> installing the binary (and the various ports systems do that, whereas >> as far as I can tell none of the rpm or apt-based systems come >> anywhere near it) makes the latter possible. That doesn't mean >> building from source has to the only - or even the primary - way to >> install a package. Just that it's shouldn't be a second class citizen. > > I would venture to guess that a significant majority of users will never > need to or want to recompile or alter the software as you suggest. > > They're going to want a stable, tested version of the software, and that > means a pre-built, pre-configured binary that's been signed by their vendor. > > Since you need or want a more flexible system, I'd suggest you discuss > it with the pkgbuild folks. > > It is highly unlikely that the IPS team will focus resources on a build > system as it won't help us reach our primary goals and the resources > spent developing are better spent on improving the primary user experience. > > Cheers, > -- > Shawn Walker > _______________________________________________ > opensolaris-discuss mailing list > opensolaris-discuss@opensolaris.org > _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
