[vbox-dev] IPS package

[Thomas Gouverneur]

Klaus, 

The current script I've been working on is doing exactly
what you describe. I'm adding a run-once service into SMF. 

I also add
an /opt/VirtualBox/VERSION file with the package's version string inside
it. 

When run-once SMF service start, it checks this file against its
latests known version and if that doesn't match, a postinstall + driver
cleaning is ran. 

How can I work with you guys to know what's
potentially currently missing and how you'd like it to be implemented?


Also, what is your possibilities at Oracle to make an IPS repository
available? 

I'd really like to get things moving in the good direction
there, IPS is really an improvement to me and I guess also to a lot of
other virtualbox users. 

If needed, we can have a call together to
discuss this further off-list... let me know. 

--Thomas 

Le 2014-04-02
17:52, Klaus Espenlaub a écrit : 

> Hi Thomas,
> 
> On 02.04.2014
14:45, Thomas Gouverneur wrote:
> 
>> Ram, As far as I'm aware, there's
no way to automatise it, although I find it better than nothing to
benefit from the IPS packaging rather than the SVR one. On another side,
we can still display a big fat warning when the user is trying to
install/upgrade with the instructions to get this done the proper way.
>

> If I'm not completely behind this isn't possible with IPS, as one of
its 
> design decisions was that a package install/upgrade/uninstall
cannot 
> ever block to ask for input or provide any output besides
requesting a 
> reboot. I don't think anyone seriously considers reboots
to be an option 
> (it's a problem, not a solution).
> 
> To reach a
good usability a VirtualBox IPS needs to be able to reliably 
> trigger
some activity for ALL of the following situations: 
>
postinstall/postupgrade/postuninstall (and it'd be nice to have 
>
preinstall/preupgrade/preuninistall for doing some truly vital 
>
cleanups). Would it be possible to use a variable component in the SMF

> run-once service name like the package version to trigger activities
for 
> upgrades (only necessary for the case of upgrading a live
system)? 
> Anything automatable in a build process is fine with us.
Trust me, we're 
> not afraid of complex implementations :)
> 
> If
these activities aren't possible then the only way would be to detect 
>
a driver/application version mismatch when some VirtualBox application

> is started, and this is where we get into the very bad user
experience 
> region: this is generally done by non-root users, who
don't have the 
> privileges to rectify the problem and have to ask the
admin to complete 
> the manual part of the upgrade.
> 
> I briefly
thought about doing a "dummy IPS" package, i.e. one which 
> simply
dumps the PKG file into some location, and use the run-once 
> service
to do the PKG install, but honestly this is several orders of 
>
magnitude too ugly to be acceptable.
> 
>> What do you think? Could this
be integrated?
> 
> We're not against IPS packaging, we'd be gladly
providing IPS packages 
> tailored for Solaris 11 ourselves if only
there would be a good solution 
> in sight which is user friendly. So
far we couldn't find any way to 
> create an IPS package with an
acceptable user experience, and that's why 
> we stick to the PKG stuff
which has the necessary hooks.
> 
> The IPS package has quite some
potential (directly installing the 
> package as part of autoinstall,
skipping the useless 32 bit binaries, 
> skipping irrelevant drivers
like the streams based bridging support, 
> i.e. reducing the package
size significantly)...
> 
> Klaus
> vbox-dev at virtualbox.org
https://www.virtualbox.org/mailman/listinfo/vbox-dev [3]

-- 
--Thomas



Links:
------
[1] https://github.com/tgouverneur/VBox-SVR2IPS
[2]
http://mdma.igh.cnrs.fr/vbox/en/catalog.shtml?show_all_versions=1&action=Refresh
[3]
https://www.virtualbox.org/mailman/listinfo/vbox-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.virtualbox.org/pipermail/vbox-dev/attachments/20140402/7f7e5850/attachment.html>