[vbox-dev] Guest Additions, co-existence of distribution and upstream versions

[Michael Thayer]

On 09.11.2015 11:46, Michael Thayer wrote:
> Dear All (especially maintainers of distributions Additions packages),
>
> I have been thinking again about our old problem with the Guest
> Additions, namely how a user can simply install (i.e. update) the
> "native" Additions which come with VirtualBox without interfering with
> the packaging system if the guest system they are using comes with
> Additions pre-installed.  My latest musings are something along these lines:
>
>    * All files installed by the Additions would be in a single folder
> (/opt/VBoxGuestAdditions-<version> for the native package, and e.g.
> /usr/lib/VBoxGuestAdditions for a distribution package).
>    * The Additions would have contain a set-up script, which distribution
> packages could run as part of their post-install, which would build and
> install (to /var/lib/VBoxGuestAdditions, not to the standard kernel
> module folders) the kernel modules and put symlinks into the Additions
> folder in place for /usr/bin/VBoxClient and others.
>    * The set-up script would also install an uninstall script as
> /var/lib/VBoxGuestAdditions/uninstall.sh or similar which would reverse
> the effect of the set-up script and allow in particular simple upgrading
> of a distribution package to a native one without needing to touch any
> files managed by the packaging system.  If this was present it would be
> called at the start of the set-up script as part of an upgrade.
>
> Do any of the relevent people (Gianfranco?  Larry?  Sérgio?  Who else?)
> like or dislike any of this, or have better suggestions?  I see that it
> would notably go against the trend of separating the kernel modules into
> their own package or even putting them into the kernel package like
> Ubuntu does.  And it would not allow upgrading from earlier distribution
> packages - we would continue to ask the users to uninstall them
> manually, which is the safest but not the user-friendliest solution.

So far no one seems to have any opinions here, so when I have time I 
will implement that.  Another point which occurs to me is that even if a 
distribution does provide the kernel modules as part of their kernel 
package, and if I do work to make sure that they can be unloaded at 
run-time, then it would be trivial to just unload them and replace them 
with ours at boot time.

Regards,

Michael

> Thanks and regards,
>
> Michael
>

-- 
ORACLE Deutschland B.V. & Co. KG   Michael Thayer
Werkstrasse 24                     VirtualBox engineering
71384 Weinstadt, Germany           mailto:michael.thayer at oracle.com

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstraße 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher