Bart Smaalders wrote:
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.
This sounds nice but what will the implementation
of this be?
If we move towards a design where there is an FMRI
that looks after each file, are we going to end up
with countless more FMRIs that are just for massaging
these files?
Is the use of Actuators synchronous or asynchronous?
And if there are multiple Actuators specified?
If I think about it, it seems to work for applications
that introduce their own files too - the FMRI is known
to them and anything else that depends on it, so updates
for that application should know where to deposit file
changes and how to have them applied.
My fear is that we are creating too many FMRIs and that
in doing so, we're creating problems for ourselves in
the future. Current FMRI count is closing in on 300 in
Nevada. Nearly 3 times the number from S10FCS. One might
therefore reasonably conclude that Nevada therefore takes
3 times as long to boot as S10FCS. (I don't know if that
is accurate, it's speculation based on numbers.) It's
not any one person/project that's been responsible for
this, it looks like like death by 1000 cuts.
Darren
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
