Brian,
Reading of IPS docs can show the IDR process is really gone. So I do not
want to decline from the real problems. Please follow my in-line reply...
On 12/01/11 15:49, Brian Utterback wrote:
This discussion makes me think that we have a couple of gaps in our
available tools. We have have been told that the depot process
delivers only those binaries that have changed when an update is done.
It seems to me that there ought to be a way to query the depot about
what files will be delivered in a hypothetical update. That is, there
should be a way to ask a depot to diff too versions of a package.
As was told dependences depends on what exactly is installed on
customers machine... so this output could be generated as part of the
explorer-data ...but it will need the catalog of the offered (update)
repo first. But let us call the file generated by the customer requiring
IDR the "IDR-map".
In S10, 9 ... we cuold generate 1 IDR for several boxes (customers) it
will not be available in IPS ...what is more... customer will not be
available to update box between generation of such "IDR-map" data and
aplying the IDR.
Such process does not seems to me to be much viable.
On a similar note, the same we should have a tool that does that
between repo, either both online or between a online repo and the repo
in your current workspace or between two workspace repos.
...same as above. Such "IDR-map" (or update map) is created when "pkg
update" is performed but it has temporary character only. ...so store
it to "named" file and transport is anywhere else as in case discussed
above does not bring anything relevant.
As far as IDR's go, we have a bit of a difficulty. While it doesn't
seem that an SRU needs to know what files are delivered, an IDR does.
And IPS does not eliminate the need for IDR's. Worse, we almost
certainly cannot provide IDR's via an online publisher, since IDR's
are potentially unique to a customer and access must be strictly
controlled. The only way I can see to do that with a publisher is to
have a separate one for each IDR, each with its own certs, and then
control the certs. Ouch.
Here is too many issues on one paragraph so I will try to give the
structure to it:
- " pkg contents -g idr-file 'idr-publisher/*' " will (most probably)
dump all the files in relief file-repo
- file-publisher (created when -a parameter of pkgrecv) is good enough
even for .mil customers :-)
- file can be send as the e-mail attachment ...or burned on CD via
land-mail :-)
- certs? Here I do not anything about application of certs on
file-publisher ...but fortunately here ale also other resources to
verify the file authenticity i.e. PGP...
So, failing that, we will need to distribute IDR's as package files.
But I doubt that including the whole package in each file is feasible.
Just a couple of unlucky changes and you could get a few of the
largest packages changed, and suddenly your IDR is a gigabyte or more.
Again ouch.
...as above parameter -a of pkgrecv can create file-publisher containing
several IPS packages ...and I will bet it was added just for the
customer support cases :-) ...I am using it when transferring new
builds to lab to test and it work fine.
Jiri
_______________________________________________
userland-discuss mailing list
userland-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/userland-discuss
