No not quite,
You can check my go port for formats and some incomplete server code
https://github.com/Toasterson/pkg6-go
My C++ port attempt for sax parsing and history format implementation
https://github.com/Toasterson/pkg6
And my current rust port for Manifest reading code and an attempt to
make things faster
https://github.com/OpenFlowLabs/ips
And the docs of the original for details from the Original developers
fom 2011.
https://github.com/OpenIndiana/pkg5/tree/oi/doc
In there is a complete manual how everything works and Implementation
details and notes from the devlopers about the algorithms and the
original reasons why things are why they are. There is a t least
conference 20 talks worth of reading in there.
-Till
On 05.03.23 17:47, Richard L. Hamilton wrote:
Thanks! That covers the useful part of my questions; for curiosity details I
can always look at the source code. :-) Unfortunately for a more than casual
overview, I'd have to learn Python. :-(
On Mar 5, 2023, at 11:19, Till Wegmüller <toaster...@gmail.com> wrote:
Hi
IPS works on images of the OS. And it does so in an Atomic way. Speed is not
the main goal. Stability is.
If you want to speed up the time it is usually good to add more RAM and faster
disks, as IPS consumes a lot of memory resolving dependencies. And doing
Catalog operation. The Actual update is alsmost instant.
A lot of the phases during package actions are spent in internal bookkeeping
things which are simply slow on OpenIndiana due to how IPS was initially
designed with releases and not rolling release. This can be fixed in the future
but I did not have time to do anything there. A update would require a couple
months worth of work and currently nobody is paying for that. It's good enough
for people as it is.
The stages you see are:
- Downloading and updating cached JSON catalogs of all packages available (this
usually takes the longest)
- instrumenting beadm
- downloading manifest files
- Downloading and copying files (uncomress) into place as described by the
manifests. (check the contents with `pkg contents -m`
- Creating a search index for pkg search actions (this also takes a long time)
Boot environments are created on updates that update more than one package. The
package can inform IPS if a new boot environment is required. Installation
uninstall etc. do not require a new boot environment.
Hope this helps
Till
On 05.03.23 16:41, Richard L. Hamilton wrote:
Given the output
----- output begins ------
root@openindiana:~# pkg update
Packages to update: 375
Create boot environment: Yes
Create backup boot environment: No
DOWNLOAD PKGS FILES XFER (MB) SPEED
Completed 375/375 5209/5209 181.4/181.4 878k/s
PHASE ITEMS
Removing old actions 1015/1015
Installing new actions 1017/1017
Updating modified actions 6585/6585
Updating package state database Done
Updating package cache 375/375
Updating image state Done
Creating fast lookup database Done
Updating package cache 2/2
A clone of openindiana-2023:03:03 exists and has been updated and activated.
On the next boot the Boot Environment openindiana-2023:03:05 will be
mounted on '/'. Reboot when ready to switch to this updated BE.
Updating package cache 2/2
---------------------------------------------------------------------------
NOTE: Please review release notes posted at:
https://docs.openindiana.org/release-notes/latest-changes/
---------------------------------------------------------------------------
----- output ends -----
what do the various phases mean? And what drives the decision whether to create
a new boot environment, or a backup boot environment (or maybe neither)?
Knowing those might be helpful if anything went badly wrong (although the simplest remedy
would be to fall back to a previous boot environment!) or if one intended to create a
package, and would certainly be more satisfying waiting for the slower phases to
complete, being able to say to oneself what it was doing then. Oh, and why does
"Updating package cache" appear twice?
Updates on Solaris 11 and derivatives (OpenIndiana, etc) are certainly very
robust (if packages and repositories are correct!) and provide generous means
of recovery. But they do seem to be quite slow compared to e.g. either Red Hat
based or Debian based Linux methods (yum or apt, or the underlying local-only
facilities). That's not counting download time either (since repository servers
are not all equal).
_______________________________________________
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss
_______________________________________________
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss
_______________________________________________
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss
_______________________________________________
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss
