Philip Brown wrote:
When the smarts are shifted to "the packaging *system*", it allows that
the package itself, be 'dumber', as far as explicit system knowledge
goes. It allows for the package to specify function, rather than mechanism.
This is a good thing.
Let's take a case in point. Various packages deliver fragments of
/etc/security/exec_attr. We could make pkg(5) know how to stitch
those together, and write a new services file - and deal w/ upgrade
issues when the format changes, including back-publishing versions of
IPS that can write the new format to all previous releases of Solaris
from which we want to upgrade. Or we could tell package developers to
place their file fragments in a well-known directory, and tag the file
as requiring the refresh of a well-known service. The latter will
work just fine across upgrades, and the well-known service can take
care of reading legacy format file fragments from older packages, etc.
In general, the OS should know how to assemble itself, and deal w/
any upgrade issues. Here's another example:
The recent hostid project moved the storage of the hostid information
on i386 architecture machines from the sysinit kernel module (which
was bpatch'd during install) into the /etc/hostid file. The initial
design for handling upgrade added code to both BFU and the installer,
which decoded the hostid from the sysinit module and created the
hostid file during upgrade. Freshly installed systems had no hostid
file, so the kernel generated one dyanmically and a SMF service
created the /etc/hostid file after boot. Since neither bfu nor
install code runs during IPS image-update operations, this strategy
did not work on OpenSolaris and the hostid was not preserved on
upgrade.
To fix this, the kernel was modified to search for a sysinit module
and read the hostid from that if /etc/hostid didn't already exist.
Only if that was not present did the kernel generate a new hostid. As
a result of this change, the upgrade code could be eliminated from
both BFU and upgrade, and the system upgrade process just works the
same in all cases.
The key design pattern here is to have the consumer of the
configuration file (here, genunix) handle the old file format/location
if the new file doeesn't exist; writing out the new file resolves the
upgrade process and completes the self-assembly.
I sure didn't want to have to teach IPS to copy the hostid around....
- Bart
--
Bart Smaalders Solaris Kernel Performance
[email protected] http://blogs.sun.com/barts
"You will contribute more with mercurial than with thunderbird."
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
