Dave Miner wrote:
Nicolas Williams wrote:
On Sat, Jun 06, 2009 at 01:19:27PM -0500, Shawn Walker wrote:
Darren Reed wrote:
I think in your case the answer is simple: you don't need to worry about
this. You should push your changes to ONNV, including SVR4 packaging
changes, and the OpenSolaris team will take care of the rest. Or at
least that's my impression.
Yup, that captures it correctly.
IPS cannot replace SVR4 packages without this issue
taken care of.
I'd call it a P1. Or else the support folks are in
for a fun time when it comes time to "patch" one of
the many /etc text files with IPS.
One answer often given is that pkgs should be "self-assembling", which
effectively means that when the software first runs it must assemble
itself, and because there's no guarantee that the first run will be with
sufficient privileges... one ends up needing SMF services to accomplish
self-assembly.
Another answer commnly given is that common cases should have IPS
actions for them -- there's a new user IPS action, for example, and it
shouldn't be hard to add actions for /etc/project and all those other
editable /etc files.
In most cases, I believe the preference would be to deliver the file
in fragments and provide SMF services to assemble the files (as in the
prior paragraph) rather than encoding that many actions into the
packaging system.
As long as we don't need service per file to assmeble, sure.
An example of a more complex problem for IPS to solve:
- if an update of a package needs to include new text in one of the
"database" editable text files in /etc that is used to build the NIS
maps on a NIS server, how does NIS get told to reubild the db?
And lets assume that the file was modified after initial install.
Do those files _need_ an SMF service?
Or is there something better that we can do?
Darren
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
