On Fri, Jun 03, 2011 at 11:53:30AM -0700, Shawn Walker wrote: > 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.
That's exactly the point. If the zone is not running, -R shouldn't be a problem at all! Otherwise, if somebody is using -R from outside, pkg might spit out a warning, that ... and ask, whether to continue. So everybody gets the flexibility and "safety" he needs. Also, as already said, take into account, that at least in our cases the SW set of a zone is fixed. I.e. the zone gets installed, than add SW pkgs are installed using -R, and finally the zone gets booted. The only time, where pkg is needed again is, when upgrading/patching occures. And since this happens in ABEs, strictly speaking, there is no need to have pkg and all its deps in a zone ... > >>>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). ... > The packages need to be refactored, that is the correct answer for Yes, and one might think about, whether SW, which is positioned as belonging to the core of a working zone, should be provided as pure binaries and thus would be independend wrt. other complex, difficult to handle/understand "eco systems" ... ;-) > minimisation. Your hacks of the package system are likely to only end > in tears and definitely lead to an unsupported system. Yepp, that's why I'm still complaining - otherwise I would just do it ;-) > >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. Hmmm, I saw the AI announcement (I guess, you mean that one): sounds promising. However, usually the servers are already there/installed and zones get added on demand later. So IMHO the AI feature wouldn't be used very often ... > >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. Yes, that's clear. However, if the system doesn't provide, what is needed, the creator can do what he wants, he'll never get it right. E.g. AFAIK there is no notion of an "optional" dependency in IPS, and thus the creator has to make a "all or nothing" decision, which doesn't make anybody happy, or split the original software in more or less fine grained packages, which might be cumbersome and annoy the users as well and probably overwhelmes the package system. But I guess, I need to explain this a little bit more: E.g. for the subversion package it is plain wrong to make it depend on apache, since subversion doesn't require Apache at all. Of course, it has a DAV extension which in turn requires Apache, but it is an extension and thus should have its own package, so that one can install it, when it is needed, and does not have to install all the apache stuff with its questionable deps, just because he wanna check out something or serve a repository. Anyway, as said and understood, just because a software comes with some "supporting"/"convinience" scripts, it is wrong to blindly make it depend on the related interpreter package and all the stuff it pulls in. A well known example for this is the openssl package. Just because of ONE simple script (usr/bin/CA.pl), which most users certainly will never touch or care about, the whole Perl* stuff gets pulled in. And as we know, today a lot of SW depends on the openssl libs, but neither the libs depend on perl nor does the related software. So because of the little script and the limited packaging system, the system gets bloated pretty soon without any need. IMHO a good PkgS would allow one to say here: optionally depends on the perl package and would provide a description field, which allows the package creator to add a note about the impact of not installing this dep ... This way one can keep the number of packages reasonable "low" but also give the users the freedom they need. > >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. And it is really plain wrong to blindly trust those tools and not to use its own human brain ... But yes, if one just wanna replicate the same crap other vendors do, it is a way to get the job done - quick and dirty. > >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. Wrt. the announcement, it doesn't look like something, I have in mind ... :( Regards, jel. -- Otto-von-Guericke University http://www.cs.uni-magdeburg.de/ Department of Computer Science Geb. 29 R 027, Universitaetsplatz 2 39106 Magdeburg, Germany Tel: +49 391 67 12768 _______________________________________________ install-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/install-discuss
