On Thu, 26 Jun 2008 15:55:09 PDT
"Richard L. Hamilton" <[EMAIL PROTECTED]> wrote:
> > > Why not adopt "rpm"?
> >
> > No way! IPS is awesome, it just needs more time to
> > mature.
>
> As far as I'm concerned, a package system (whatever it looks like):
> * bundles a set of files that must be installed as a unit
> * provides sufficient information to in some sense verify package integrity
> (checksums are really too minimal, signatures would be much better)
> * provides for metadata sufficient to deal with dependency verification and
> other special needs; this should be extensible to handle future developments
> * provides for retaining sufficient metadata on installed packages to later
> verify their integrity after installation
> * provides tools to add, remove, and update packages
> * a comprehensive package system at least defines a mechanism whereby
> updates may be obtained.
>
> Considerations lending themselves to speed, efficiency, and ease of
> maintenance
> and updates also apply.
I'd not call that a package "system"; it's more like a format + simple
management tools. I.e. rpm (the format + the single command) meets
that, but is otherwise about the worst "package management system"
I've ever dealt with. It really needs one of the upper level tools
(like yum) to be noticeably better than tar.
To paraphrase what others have said: the value isn't in the package
system, it's in the ecosystem. The number of packages available for
your system is a pretty direct measure of the value of the ecosystem.
The thing is, a random collection of packages built by random
individuals at random times isn't an ecosystem, because the underlying
set of dependencies for each will be different, so only a small
fraction of the packages will work on any given system.
Hence, the package tools - at the user end - requires a lot more to
qualify as a "system".
- it needs the ability to automatically install or upgrade any
required dependencies for the package you want. Going through umpteen
levels of required libraries to get to the point of installing the
software you need is no fun.
- it needs to know when it's about to update a package that other
things depend on, and either arrange to preserve any bits that will
break those things if they are updated, or to update said other
package at the same time (and yes, you *really* need both options).
- it needs the ability to install "alternative" versions of things
that are part of the operating system instead of part of the
repository, and hence may have different update cycles.
Most modern package systems gets the first of those right. IPS seems
to be doing a good job on the second as well - or at least one of the
options, whereas most other systems seem to ignore the issue. Most of
the package systems I've dealt with either ignore the last one, or
ignore large chunks of the OS (as recently discussed re: Blastwave).
Of course, none of this does you any good if the package you want - or
one or more of it's dependencies - isn't available in the repository
for your system, or is only available in the old version that was
available when the distro was cut. Hence on the provider end, you
need:
- a build system such that creating a complete set of packages for a
new distribution of the OS is at *worst* as hard as creating an OS
distribution (in fact, adding select packages to the distribution
should be part of the distribution build process).
- a build system that lets you easily updated the repository at
regular intervals as the maintainers update their packages.
"Complete" is a relative term: some packages may not work on your
architecture, may be binary and not available for it yet, may not
build on it because you've broken the tool chain, may have licenses
that disallow redistributing the binary, etc. So you need ways of
flagging packages as broken, for specific architectures, or not for
redistribution, etc.
Personally, I'm spoiled. The package systems I use regularly also have:
- variant build capabilities, allowing the user to set compile-time
options either globally or per package, and automatically build a
given package and it's requirements customized to their taste as
easily (if not as quickly) as installing the package.
I believe that's important, but I suspect most people simply won't
care.
<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
