Bart Smaalders wrote:
... 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.
>...
I sure didn't want to have to teach IPS to copy the hostid around....
In normal usage, the metatopic we are discussing, can be generalized as
"interfaces between OS <-> packaging system <-> package"
However, when a package is specifically intentioned to change the OS itself,
then you have fundamentally broken the abstraction layers of the APIs, and
so all bets are off :-)
I think that any packages that change fundamentals of the OS, are out of
scope for the more generally applicable concepts on the table.
That being said; certainly, IPS has a design requirement of being able to
update the OS. However, in my opinion, that requirement, should not overly
skew normal package operations.
Which is a long way of saying, I agree with you that not having IPS coded to
"know about" handling that, is the most appropriate way to go. For multiple
reasons;
firstly, because its a "change OS fundamentals" operation. Secondly, because
it is a one-time-only operation.
IPS APIs should only be instituted for things that have multi-package
multi-use application.
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
