IPS has the concept of a "filter" on an image. For example, a particular
file can be tagged with an ISA tag (sparc or x86) and then the image has
a filter of ISA=x86. Once this is done, only those files that are
either tagged with ISA=x86 or that have no ISA tag will be downloaded.
This eliminates the need to have multiple packages merely for supporting
multiple ISAs.
These tags can also be used to specify files being for documentation,
localization, etc.
So it seems that the reason #2 below shouldn't be a reason for splitting
packages with IPS.
Tom
Alexander Vlasov wrote:
Peter Tribble wrote:
On Sat, May 17, 2008 at 2:22 PM, Lewis Thompson <[EMAIL PROTECTED]> wrote:
The benefits to these more fine grained packages are obvious: we can
upgrade totem and rhythmbox independently of each other (and we make
it easy for third-parties to release updated packages)
They can be upgraded independently of each other trivially in either the old
or the new way. With Solaris/SVR4, you just release a patch containing the
changed files; with IPS you issue a new version of the whole package and let
IPS just update the files that have changed. What you can't do with IPS (but
could with SVR4+patches) is to arbitrarily freeze either component.
The drawbacks... I'm hard pushed to think of any
More packages to manage is bad, as is the diversity of installed configurations.
With bad package manager only.
And if we're pursuing popularity -- diversity cannot be avoided. Sure
it's somehow harder to support, but it's possible to stand against this
issue
The only reason to split components into separate packages is if it
makes sense to install one component but not the other. (For your example,
this may make sense, of course.)
I can imagine at least two more reasons:
1. when required part may be provided by different packages (imagine
some tool using... say, sound encoder. It may use some helper provided
by authors or third-party tool, like lame or ogg encoder)
2. splitting package into arch-dep and arch-indep ones. Imagine game
which comes with 500 MB of data (levels, music etc). With two
architectures, sparc and x86, it's better to have 10 MB sparc package
(game), 10 MB x86 binary package (game) and 500 MB
architecture-independent package which can be installed on both types of
machines (game-data)
We really need to reduce the number of units of installed software that
we need to manage, not increase that number. (The unit doesn't have to
be the package, of course - we could have groupings above the package
level.
From my system administrator experience it's better to have minimal
required subset installed -- because it's easier to manage. OTOH,
grouping software in large pieces makes it easier to manage for
maintainers, but to reach success on the market we should fulfill
customers' meeds, shouldn't we?
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
begin:vcard
fn:Tom Mueller
n:Mueller;Tom
org:Sun Microsystems, Inc.;Update Center/OpenInstaller Software
adr:;;21915 Hillandale Dr;Elkhorn;NE;68022;USA
email;internet:[EMAIL PROTECTED]
title:Senior Staff Engineer
tel;work:877-250-4011
tel;fax:877-250-4011
tel;home:402-916-9943
x-mozilla-html:TRUE
version:2.1
end:vcard
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
