On Sat, Jun 13, 2009 at 1:24 AM, Bart Smaalders<[email protected]> wrote: > > IPS will (when finished) strictly enforce the following policies: > > 1) All package dependencies are enforced: > If a package has require dependencies, they will be installed. > Packages may not be uninstalled if another package depends on them. > Incorporations and minimum required versions are enforced. > > 2) The only action that's allowed to be duplicated in multiple > packages that can be installed at the same time is a directory. > > If these restrictions are too onerous, you don't need a packaging > system but tar or cpio may do what you want.
So, you're saying that delivering software via tarballs is better than using IPS? > Why do we feel this is the right choice? > > Because the job of the packaging system is to manage software > on the machine according to the constraints imposed on that software > by its developer, and by the administrator. Yet you're denying administrators and customers the ability to impose those constraints. Dependencies are a case in point. They are simply input to a policy. A sensible default policy may be "follow the dependencies and install everything along the way". Some others may want to say "stop dead in your tracks if you need to install something that isn't already installed or that I've explicitly asked for". Another possibility is "do what you're told and ignore any dependencies". All have their place. The packaging system should enable the implementation of those policies, not unconditionally force its own policy decisions on users. > If as an administrator you wish to break package dependencies, divide > packages in half, etc, you need to repackage the software, because > you're now using it in a manner un-envisioned (or perhaps seen only > in a nightmare) by the original packager. All the tools necessary > to do this will be part of OpenSolaris. And you'll support a system where someone has modified the dependencies of a package so the system doesn't work? They've done it in the approved fashion. > The design of variants/facets was specifically targeted at allowing > the package developer to describe a variety of different configuration > options. If this mechanism doesn't provide sufficient flexibility, > please speak up.... I've not completely explored the full range of options that facets would allow, but does it allow the installation of any particular facet without any other component of the package being installed? In particular, if documentation were a facet, would I be able to install the documentation on its own? (This is something I do all the time, so I can access documentation locally on my desktop where it's nice and snappy.) > but allowing administrators to perform ad-hoc > install-time overrides of the packaging system constraints is akin > adding bpatch support to pkg. If the packaging system is so inflexible that administrators are unable to define or implement the policies they need to, they have several options, including (a) being miserable, (b) violating the packaging system by going behind its back, (c) using a different packaging system. I'm not looking forward to living in such a world. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ _______________________________________________ indiana-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
