Bart Smaalders wrote:
The more the packaging system knows about Solaris internals, the more
difficult it is to make upgrade work across a wide variety of releases.
I think that is an incorrect, or at best, ambiguous statement.
Unfortunately, I'm not aware of nice simple language to make it cleaner, so
my restatement is going to be a bit messy.
A more correct version of it would be,
"the more low-level the packager<->package API is, the more difficult it is
to make upgrades work across a wide variety of releases".
Examples of what I mean:
== More difficult, less future-proof API ==
An explicit "put stuff in your package [like this], if you want
/etc/system to be updated [like that]"
== Not difficult, more future-proof API ==
"Put stuff in your package [like this], if you need a named 'services'
definition to be added"
Technically, the less future-proof, less "knowlegable" packageing system
given by the first example, could provide a mechanism to update
/etc/services, through some kind of generic "modify file" interface. The
packaging system itself could know nothing about the concept behind
/etc/services at all.
However, the MORE future-proof approach in the second example, neccessitates
*MORE* knowlege of the solaris internals, on the back end, for any
Solaris-release-specific implementation of the packaging system. It needs to
know exactly how the "services" tables are implemented.
Then, if in the future, the services registry is changed to be pure xml, the
original package wont care, and it will install just as correctly on the new
OS version, because the back-end packaging system specific to that OS
release, will take care of it.
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.
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
