Hi Tom, Tom Whitten p??e v st 13. 01. 2010 v 15:18 -0700: > Scott Rotondo writes: > > > Manifest files will be imported from a new location that is available > > > at the time Early Manifest Import is executed. Root (/) will be > > > available, and as part of that /lib will be available. Therefore > > > manifest files located under /lib/svc/manifest and > > > /lib/svc/manifest/site > > > will be imported during the execution of Early Manifest Import. > > > As part of this project, the ON manifest files that are currently > > > delivered under /var/svc/manifest will be moved to /lib/svc/manifest. > > > After this change, the recommended best practice is manifest files > > > be delivered under /lib/svc/manifest subtrees to take advantage of > > > Early Manifest Import. > > > > This (logical) recommendation leads to another question: Is there a > > particular situation where one should prefer/require late import of a > > manifest? > > We wanted to continue to support manifest in /var, so that non-ON > consolidations and third party developers would not need to abruptly change > their packages. > > > > > If not, would it make sense to eliminate Late Manifest Import and leave > > /var/svc/manifest as a symlink to /lib/svc/manifest? > > In the early phases of the EMI project, we actually considered making > /var/svc/manifest a symlink. The feedback that we received, however, > indicated that it would no play well with SVR4 packaging. See > http://mail.opensolaris.org/pipermail/smf-discuss/2008-April/004111.html. > We also received indications that the symlink would not play well with > pkg(5), but I don't have any emails that I can refer you to for that. >
But that is problem of packaging system (both of them), which should be fixed to deal with such situations (is it the first time when we are doing such change on filesystem hierarchy?). Why should we introduce such misleading "duplication" of places? Any benefit to have 2 places? Best regards, Milan
