On Tue, Jun 9, 2009 at 1:38 AM, Bart Smaalders<[email protected]> 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.
How does self-assembly interact with modifications to a file from external sources? I can see how it works - and works well - in cases where the only correct version of the constructed file is that built up be self-assembly. But what if the file were an administrative file that could be edited by an administrator (either directly or through some tool such as cfengine)? How do you ensure that subsequent re-assembly of the file doesn't lose the external edits? -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
