>> IPS requires that all packages be able to be installed into a >> non-running image, so we do not support scripting as package >> developers never seem to understand that the software they're >> installing might not be able to run right now.
>That is nothing more than a difference of personal opinion, and therein >lies the problem. >Like I wrote before, your (Sun Microsystems') customers differ vehemently >in that opinion. I know this, simply because it is my job to know, and it >put the bread on the table. What is the definition of a packaging system then? If installation and removal are unrestricted, and custom logic hooks are allowed at every point, aren't you just left with a standardized installer (we already have) and a centralized repo? Given the choice, would you rather have package installation be consistent by design, or chance? Personally, I'm happy that Sun is taking the time to carefully engineer something that is the foundation of a great deal of other handy features. >Now, the difference of opinion is: when the last package is installed, it >"activates" the software. In my particular case, that last package is >something like ABCDpowerdns-oracle-db, which creates the PowerDNS Oracle >database, using the packages listed above. In the postinstall phase, a >specific initPOWERDNS.ora is created, modified to suit that particular >database instance, then the SPFILE is crated, then the CREATE DATABASE >statement is executed. Following that, standard >$ORACLE_HOME/rdbms/admin/*.sql scripts are run, which generate the >necessary Oracle structures inside of the database. >Finally, the POWERDNS schema is created and necessary privileges are >assigned. >After that, the listener is configured and started. None of this sounds like something a package manager should be responsible for. If you are deploying packages to a live system, then you will have some other means of hooking in custom logic, correct? An argument could be made for ease of administration, but I think it's clear that the extra logic should be separate from the package. Hey, I have some ideas. I'm not in a position to implement these, but I'm curious. If IPS supported these, would they satisfy your needs? 1) An "action" package. Just a bundle of custom logic, scripts, binary, etc. They could keep state like a real package, or leave no trace. With state, it could have separate install and uninstall logic, versioning, and who knows, upgrades. Without state it would simply execute, leaving the burden of dealing with multiple invocations up to your script. They would leverage most features of IPS - delivery, dependencies, repository, etc. 2) Ability to attach these, at the repository level, to actual packages. Meaning that a real package would not be allowed to declare a dependency on an action, but the opposite could be true. This is supposed to allow pre/post install behavior. Call it aspect oriented package management or something. I'm not at all familiar with IPS internals, so please forgive me if these don't make any sense. I just have a hunch that something like the above would give those who rely heavily on scripting in package installs less to complain about. Regards, Steve -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of UNIX admin Sent: Wednesday, June 17, 2009 2:13 AM To: [email protected] Subject: Re: [indiana-discuss] "no scripting zone" and isaexec(3C) == > Of course not, and it's not required with IPS today. Now I'm confused; first you wrote that the service would have to be started upon reboot, then you write that it's not required. Which one is it? > If you did want to be able to provision a new boot > environment, > it would be nice not to have to start Oracle as part > of the > postinstall script, though, wouldn't it? Actually, that part has already been solved, namely (System V packages): ABCDoracle-user ABCDoracle-inventory ABCDoracle-libs ABCDoracle That's the minimum required to install 32-bit Oracle on an i86pc system. All packages depend on ABCDoracle-user. ABCDoracle depends on ABCDoracle-inventory and ABCDoracle-libs. ABCDoracle-user, ABCDoracle-inventory, and ABCDoracle-libs are perfectly installable with pkgadd -R. However, ABCDoracle is NOT installable onto a non-live system, because as part of the init.ora configuration, some parameters, like "paralell_max_servers", whose formula is 4 x number of CPUs, must be calculated dynamically, since they are different for each system. > IPS requires that all packages be able to be > installed into a > non-running image, so we do not support scripting as > package > developers never seem to understand that the software > they're > installing might not be able to run right now. That is nothing more than a difference of personal opinion, and therein lies the problem. Like I wrote before, your (Sun Microsystems') customers differ vehemently in that opinion. I know this, simply because it is my job to know, and it put the bread on the table. Now, the difference of opinion is: when the last package is installed, it "activates" the software. In my particular case, that last package is something like ABCDpowerdns-oracle-db, which creates the PowerDNS Oracle database, using the packages listed above. In the postinstall phase, a specific initPOWERDNS.ora is created, modified to suit that particular database instance, then the SPFILE is crated, then the CREATE DATABASE statement is executed. Following that, standard $ORACLE_HOME/rdbms/admin/*.sql scripts are run, which generate the necessary Oracle structures inside of the database. Finally, the POWERDNS schema is created and necessary privileges are assigned. After that, the listener is configured and started. The database is now up, running, and ready to accept and serve out data. As you might have noticed, this all happens automatically. And it happens the same way each and every time, for each and every database. And it works on a live system which is in production. These packages, together with this concept, have the capability to be deployed on a massive, unlimited number of live production systems. It is consistently repeatable. The only drawback is that it cannot be installed on a non-live system or a diskless or an AutoClient from the install server. However, considering that for this tradeoff, I get databases, DNS, firewalls, mail, web and just about any other server at the mere push of a button, it's a small price to pay. Main difference between your opinion and my experience is that you say: it must be installable on a non-running system, and I say: when I install it, it must run immediately and without any kind of manual intervention. So soma packages are installable on a non-live system, while others must be installed on a running system, because 1. the server must not be rebooted under any circumstances 2. we need commands like psrinfo(1M) to run on that particular server in order to obtain information used to configure further (psrinfo(1M) is just one of the examples). IPS, it seems does not offer the choice. And it should. Judgding by what I saw and experienced, consistent repeatability is needed more than being able to install on a non-live system. I'm not asking that you start producing packages which break installing on a non-live system, just that IPS give me the option to choose in which way I will use it, concretely, I want to be able to execute arbitrary code, just like I'm able to do so in "preinstall", "postinstall", "preremove" and "postremove". Another option would be, that I'm able to remotely svcadm enable SMF FMRIs. For example, SD-UX has such capability, and has had it for the past twenty years or so. I see no reason why "the most advanced operating system on the planet" could not have it also. -- This message posted from opensolaris.org _______________________________________________ indiana-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/indiana-discuss Confidentiality Notice! This electronic transmission and any attached documents or other writings are confidential and are for the sole use of the intended recipient(s) identified above. This message may contain information that is privileged, confidential or otherwise protected from disclosure under applicable law. If the receiver of this information is not the intended recipient, or the employee, or agent responsible for delivering the information to the intended recipient, you are hereby notified that any use, reading, dissemination, distribution, copying or storage of this information is strictly prohibited. If you have received this information in error, please notify the sender by return email and delete the electronic transmission, including all attachments from your system. _______________________________________________ indiana-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
