Hi all, Sorry for the late reply. With all your feedback and Liane's help, I have revised the last "Concerns and proposed solution" section to clearly specify the concern and the possible solutions and trade-off. My apology if the previous one delivered any unclear statement.
Concerns and proposed solution ------------------------------------------ As proposed in the write-up, ON manifests currently delivered to /var will be moved to /etc to take advantage of early import. The only concern we have is the 3rd party and non-ON which can still reference and deliver manifests into /var. To address this concern, I am proposing the following solution: (1) Continue to support /var/svc/manifest by importing manifests in /var/svc/manifest after /var is mounted. (2) Explicitly move manifests delivered by ON to /etc. (3) File RFE's to have other non-ON Sun delivered manifests delivered to /etc. (4) Document the changes so 3rd parties are aware of the changes. Alternatively, the SMF upgrade code can explicitly move all manifests (3rd party and Sun-delivered) to /etc/svc/manifest, and make a symlink or lofs mount to make /var/svc/manifest point to /etc/svc/manifest so the 3rd parties who delivery service manifests into /var can continue to do so without need of changing their packaging. The downside of this alternative is that the packaging tools may give warnings during pkgadd or pkgadd -R (if we use symlink or lofs) about different declarations of /var/svc/manifest. The packaging tools may need to be changed to handle this special case and that may well be a significant implementation that we'd prefer to avoid. Given that most 3rd party packages don't require early manifest import and those which do are normally willing to make package change to avoid the ugly workaround, the proposed solution seems to be the right way to go since it is easy to implement and does not require changes in packaging tools. Packages which avoid this proposed implementation now can alway take advantage of it in the future. Thanks Steve Liane Praza wrote: > Jordan Brown (Sun) wrote: > >> Nicolas Williams wrote: >> >>> On Mon, Apr 07, 2008 at 04:31:28PM -0700, Jordan Brown (Sun) wrote: >>> >>>> When my package delivers a manifest into /var/svc/manifest, it is >>>> required to deliver directory entries for /var, /var/svc, and >>>> /var/svc/manifest. I'm not sure what happens when you install my >>>> package onto a system where one of those is a symlink. I think the >>>> symlink gets removed and replaced by a directory, but I'm not sure. >>>> >>> Required is a bit strong. We do it for SUNW pkgs, but a package without >>> those directory entries will install just fine. >>> >> I don't have time right now to do the experiment, but I believe pkgmk >> will at least whine and quite possibly fail if you don't include them. >> (I agree that you can install a package that doesn't include them.) >> >> >>> A pkg with those entries will install with manual (or admin(4)) >>> intervention in a system where /var/svc/manifest is a symlink. >>> >> ... and what fraction of 3rd party installers that are invoking pkgadd >> will have set the admin variable to the right state? >> >> >>> But why not make it a lofs mount and be done? >>> >> That would work. I'm not totally comfortable with it - can't say for >> sure why; I'm just not used to using lofs to remap the file system - but >> it would work. >> > > I think it wouldn't work because it'd always need to be lofs'ed together > during an alternate root package install. > > I suspect Steve has gotten the strong feedback from everyone on this > one. I certainly continue to believe that existing, packaged, > third-party manifests shouldn't have to change their packages to > continue to deliver into /var/svc/manifest/*. > > Let's let Steve ponder and come up with a revised proposal on this > point. I'm currently not convinced that the symlinks buy us enough to > bother with the maintenance burden and potential confusion they might > cause. (Not having them in either direction breaks no currently > committed interfaces, with the possible exception of profiles, which can > be handled differently.) > > liane > _______________________________________________ > smf-discuss mailing list > smf-discuss at opensolaris.org >
