Bugzilla – Bug 2152
standalone package support needed (on-disk format)
Last modified: 2010-01-19 23:31:25 UTC
You need to log in before you can comment on or make changes to this bug.
IPS packages need an active and accessible repository in order to access them. They need to have a standalone mode. Consider the following use cases (recently both encountered). 1. A network driver in an IPS package format. If you have an opensolaris image but you need a third party network driver, you can't access the network yet. 2. Sensitive corporate information. Many corporations don't want sensitive corporate information, network topology, internal server names, etc. out on the open internet. Logging in through a portal and downloading a package from a web site is considered acceptable. 3. Many people's mode of initial installation involves having a bunch of packages on a USB stick or CD drive. A standalone format would solve this issue.
As a comment, all of these scenarios are also addressible with a locally accessible repository, whether on stick, on LAN, etc. (This RFE is usually called "need on-disk format".)
From a Sun business view there are, unfortunately, due to US export reasons still some packages that won't be allowed to be published in an internet facing repository (from Sun - they can be "online" inside the customer environment). These do need to be delivered to the customer in the software package format of the system (so SRV4 now and IPS in the future).
There are also government or other regulated sectors that have the majority of systems disconnected from the public internet, or even from their own private network. They don't even want to start up unnecessary processes (e.g. small, localhost-only pkg.depotd's) to install software. They want the package represented in a file, installed by a piece of software that does not do any networking of any kind whatsoever. Having an on-disk representation of uninstalled software makes it easier to use existing tools to store/catalog/control (think ITIL change management), and being able to install it with a standalone, non-networked application are common requirements from these kinds of users.
Interesting that they're unwilling to run an auxiliary program (standalone depot server) to install packages, but they're perfectly willing to run thousands of auxiliary programs (via postinstall scripts) in the old system. Network connectivity isn't an issue -- the auxiliary depot needn't listen on anything other than localhost, or even a unix domain socket. The on-disk representation is the depot format. As for cataloging it, it's a black box -- it can and will change, so diving into its innards is as silly as diving into the innards of an ELF file to catalog its individual sections. We do want to make it convenient to pass packages around on pieces of physical media and install them from same without having to do all sorts of extra manual work. That's the goal of this bug. The details of the implementation are Private (in the ARC sense) and not really important to customers (other than the usual resource and security constraints).
This really has nothing to do with the depot server; it's more of an API support issue.
*** Bug 2660 has been marked as a duplicate of this bug. ***
It unclear to me from the evaluators' comments whether or not they plan to address the bug as originally filed as there are several assumptions listed here about the original request. This request is for standalone packages that can be downloaded individually and referenced by the pkg command and the pkg command alone. If the evaluators choose to implement this in a way such that there is a one package depot with a small disk footprint, that is an implementation detail. (I get the impression this is the current direction, I could be wrong). It needs to be done in such a way that a third party package developer can easily construct a standalone package or package depot with no access to any unattached depot. If you had a sparsely populated mini-depot where the details of depot processes running were hidden from the user and done automatically by the user running the pkg command, it's probably ok. The point is, the user shouldn't know or care and the IPS package developer needs to have an easy way to create this package also. The current IPS packaging tools are quite straightforward to use and automate. Can the evaluators please elaborate on what they plan to do here so that we can make sure that request is understood by the numerous parties on this bug report. I think we're in agreement, but I want to make sure before it is too late.
(In reply to comment #7) > Can the evaluators please elaborate on what they plan to do here so that we can > make sure that request is understood by the numerous parties on this bug > report. I think we're in agreement, but I want to make sure before it is too > late. This has not yet been designed or sufficiently discussed, so we can't elaborate in much detail at this time. That will happen later this year. However, I can tell you that both developers and users should be able to retrieve or publish packages using the included pkg tools (not just pkg(1); it might be pkgrecv(1), etc.). It is also planned that this be as easy as possible within reason.
This won't be making 2010.x.