On Wed, 22 Oct 2008 16:28:13 -0500
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.
You're absolutely right. But the question started with "What's it
going to take to get a package system up to the selection and update
frequency of Debian's apt". This is a *very* desirable thing, as
otherwise you wind up driving users to build things themselves, which
is taken as not happening, so to be avoided at all costs, or to
running packages from multiple vendors - which is generally a worse
fate than trying to build things themselves, leading them to finally
punt and use systems that have packaging systems that offer them the
tools they need.
The answer came back - from a couple of sources - that it was going to
happen after the repositories were opened up to external
submissions. That would seem to be directly opposed to the idea of
only having pre-built, pre-configured software "signed by their
vendor." In fact, limiting the package repository to those that a
single vendor has time to build and sign pretty much means it'll never
be able to compete with the likes of apt, much less a good port system
- which sounds like a recipe for failure. Having lots of such
repositories just means you'll have to install lots of variants of the
support and framework software - that everyone spent time building -
to reach a few edge applications, but even the sum will clearly be
less than a single repository that all those people could have
contributed to.
Once you've decided that having a good package selection matters
enough to open up the repository to external submissions, your goals
need to change. In particular, you need to add goals that encourage
people who port software to your system - which is, as you imply, a
minority of your users - to create new packages and contribute them
back to the system. *These* are the users who will want - and use -
the ability to build customized versions of packages without having to
do the port from scratch. In fact, the ability to do that may be the
difference between porting just the config they want and doing a port
that's use full to anyone that they then configure to be what they
want.
<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
opensolaris-discuss@opensolaris.org
