On Mon, 2008-05-19 at 09:45 -0500, Tom Mueller wrote: > 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 this is very interesting and it sounds like something we could use in pkgbuild to structure the package contents without splitting them. Unfortunately I couldn't find out more about this feature, so I have some questions. The goal would be to package all components of an application in one package and use tags to identify: - development files (headers, pkg-config, devel docs) - documentation (man pages, online help, devel docs) - l10n content (message catalogs, man pages, online help) Is it possible, and if so how, to do the following: - initially install only the (untagged) runtime bits - add one more locale (i.e. files tagged for that locale) of a previously installed package - add the development files of a package previously installed without them - delete files belonging to a locale - apply similar changes to an entire image Thanks, Laca > > > 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
