On 06/02/11 20:39, Jens Elkner wrote:
On Fri, May 27, 2011 at 12:59:08PM -0700, Shawn Walker wrote:
On 05/27/11 12:15, Jens Elkner wrote:
...
However, at least for native, not running zones I can't see any reason,
why one should not use -R. IIRC in contrast to pkgadd IPS is not running
any pre/post install scripts anymore. So it basically comes down to a
But it does allow packages to restart, disable, and/or suspend active
services managed by SMF. That won't happen if you run the command using
the alternate root option for obvious reasons.
If the zone is _not running_ there is no need to restart, suspend a
service. And IIRC SMF states are save in a persistent store (sqlite db?)
and I don't see a reason, what IPS prevents to make use of it (i.e. use
an appropriate lib to read/modify it, e.g. to enable/disable a service)
or simply put a "dumb" startup script into $ZPATH/etc/rc?.d ...
But what if the zone is running? What if the zone is in a specific
state? What if...? That's the whole point of the packaging system, to
ensure the user doesn't have to worry if the zone is running or not,
among various other things.
...
Actually, one doesn't really need pkg in a zone, as long as the global
zone admin is the zone admin as well. And if one starts removing pkg,
one can continue with python (I mean, who needs this? ;-)), than tcl/tk,
which opens the door to remove the X11 stuff and groff => ~175 MB less,
and now we would have something, 234MB vs. 407MB /, I could start with
without a bitter aftertaste - i.e. probably would not miss sparse zones
than (except its read-only fs features).
Usually, we would add the jdk and/or some convinience stuff and end up
with ~515 MB (would be nice, if the visualVM would be a separate pkg,
since not needed in a zone: ~ -30 MB). For that we certainly need to use
pkgadd (since pkg has still no relocation switch aka "-a none") - another
reason to remove pkg and company from the zone and do the
install/uninstall from outside ...
I think you need to approach the problem differently.
Hmm, well, just trying to plumb the depths of IPS/new zones. And 'til
now nobody came up with a suggestion to solve the problems not only we
have, i.e. minimize space consumption of/number of packages need to be
maintained in a zone, simplify SW/zone management.
The packages need to be refactored, that is the correct answer for
minimisation. Your hacks of the package system are likely to only end
in tears and definitely lead to an unsupported system.
Your solution
seems far more complex that necessary
Hmmm, for me it turns out to be pretty simple: When I create a zone, I
need to determine, what SW and resources it needs/what service it should
run. So at least in theory why shouldn't it be possible to give the zone
install a "list of packages" it should install. I guess, under the hood
it is using such a list (wherever it comes from). Why not making it
customizable?
That's possible even today, and is even easier in recent builds.
IMHO your are making it much more complex, than it has to be, because you
are not considering the circumstance/environments, under which the SW is
actually used. I guess, 90%+ of the users, which actually run a machine
with zones, are doing it similar and as simple as we do: i.e. the admins
of the global zone are the admins of the non-global zones as well. And
thus there is not really a need to have the pkg SW within the zone
installed. Basically, what annoys me is not the pkg SW itself, but the
whole bunch of dependencies it introduces to the system: i.e. on servers
- Who needs python?
- Who needs tcl/tk today?
- Who needs X?
- Who needs the groff etc., when man pages are not installed anyway?
- And who usually needs perl?
The dependencies in packages are there because (ignoring bugs) a package
creator has determined that for the software to function *in a supported
fashion* certain things must be installed. The package system is there
to provide a *supported* way to install and update a system.
And this leads to: Much higher space consumption as really necessary of
course but also to unecessary downtimes/security risks! Why, because the
package software is not really able to determine, whether these packages
are actually used and so if installed, they need to be "patched" as well,
which in turn yields into to an unecessary reboot ...
All this remembers me on an OS, we are trying to avoid to use ;-)
A significant amount of work has gone into the new packaging to ensure
that dependencies listed are actually needed. In fact, the package
system even comes with a special tool that allows package creators to
perform automated dependency analysis based on things like elf libraries
and the #! line in scripts.
So a nice to have would be something like:
zone install swtemplate=...
(and actually the OS may provide some "common" templates) as well as
pkg depend -r $package
You will be able to provision zones using AI, which will give you that
"template" functionality.
-Shawn
_______________________________________________
install-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/install-discuss
