> Date: Tue, 10 Oct 2006 15:19:00 +0100
> From: "Enda O'Connor ( Sun Micro Systems Ireland)" <Enda.Oconnor at sun.com>
>
> Sarah Jelinek wrote:
> > Enda O'Connor ( Sun Micro Systems Ireland) wrote:
> >
> >> Casper.Dik at Sun.COM wrote:
> >>
> >>>> Hi
> >>>> I guess setting start/exec for the service:instance in question to a
> >>>> startup script other than say fs-user would do ( just in the
> >>>> miniroot repository ), but again this is messy I guess.
> >>>
> >>>
> >>>
> >>> How is the repository build for the miniroot.
> >>>
> >>> If you think that that is messy, I think it's much cleaner than
> >>> the current situation.
> >>>
> >>> Casper
> >>>
> >> To be honest I have no idea how the repository is built in the
> >> miniroot, I don't disagree that it is probably a beter idea that we
> >> have currently have ( which would not be hard ) :-)
> >>
> >> Would we then need to ship a dummy file to cover all the exit 0 cases,
> >> or is their a better way of manipulating the svc stuff to just have
> >> fs-usr not do anything, just return 0?
> >
> > Enda,
> >
> > I am not clear as to what you are proposing. Once the patches are
> > applied these files get overwritten. So, we would have to modify the
> > files for all of the services to know when running in the miniroot they
> > should simply exit 0. That way when and if they are patched in the
> > miniroot we do the right thing still. However, today there is no
> > standard way that we export from the miniroot to know if you are running
> > in the miniroot. Applications that need this data find ways to get this
> > data.
> >
> > In the case of the customer issue I was dealing with it wasn't fs-usr,
> > it was devices-local.
> >
> > sarah
> > ****
> >
> I am assuming that say in the miniroot we had start/exec for these files
> just returing 0 ( a dummy file ) in the repository DB. ( just in the
> miniroot now mind )
> If we installed a patch that say delivered fs-usr to the miniroot, but
> filesystem/usr start/exec was calling some dummy file, instead of
> fs-usr, the patchadd should not modify that surely, ie the start/exec of
> filesystem/usr:default
>
> Enda
> >>
> >> Enda
The miniroot repository build process was changed in S10U3 when SBD
backported in the ON-gate
6271324: boot-archive.xml is delivered into the wrong directory
and in the install-gate
6272742: Install gate should not depend on the build system's
manifests to build the miniroot repository.
After these changes, the ON-gate delivers usr/sbin/install/miniroot.db,
which the SUNWsibi postinstall now copies to etc/svc/repository.db in
the miniroot, and then further manipulates for use in installation. It
would seem that updating via this postinstall script of the exec
methods called for in the miniroot repository would be better than
whacking the method scripts themselves. The unfortunate part is that
an ON-patch updating usr/bin/install/miniroot.db will still need to be
followed by the execution of the SUNWsibi postinstall.
-JZ
