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

[Michael Thayer]

Hello Gianfranco,

On 11.11.2015 14:51, Gianfranco Costamagna wrote:
>> On 09.11.2015 11:46, Michael Thayer wrote:
>>> 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).
>
> /usr/share/virtualbox/VBoxGuestAdditions.isofor Debian :)
>
>>>     * 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.
>
>>>
>
> I wouldn't use this new implementation in Debian I guess, mainly because we provide a virtualbox-guest-dkms
> package that should be enough for the users, and if the guest-dkms fails
> (because of too new kernel or something else), users can always use our virtualbox-guest-additions-iso
> that basically provides the iso image from Debian repository

Just for information, we have removed DKMS support on the development 
branch, because it did not have any advantage for us.

> I'm not sure if the method you are providing will be implemented inside the iso file, will it?
>
> (I mean: released the script as part of the iso image)
>
> in this case I should have no problems, because users are on their own
>
>
>>> Do any of the relevent people (Gianfranco?  Larry?  Sérgio?  Who else?)
>
> thanks for this :)
>
>>> 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.
>
>>
>
> this is really unfortunate and mitigated by the new shiny updates that went into stable debian and
> (soon) ubuntu releases.
>
> Upgrading from 4.3.18 to 4.3.32 or whatever fixed so much things, so I'm at least happy for now
> (mainly because the guest-dkms module now builds fine with new kernels too)
>
> the problem is that you release for older branches only (or almost only) when there are CVEs
> (or at least I can uploading to security only when CVEs are found)
> so this solution doesn't scale in general.
>
>> 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.
>
> mmm this is risky AFAIK, because the problem with ubuntu modules is that they aren't even built, and if they are
> built I don't understand the reason for removing and replacing them...
> do you think your modules might be better?
>
> (I guess this solution might be also "check if the module is running, if not try to make it work with another fallback module")

We never know how up-to-date the modules which come with the 
distribution are (though presumably if the user knows they are 
sufficiently up-to-date they will not bother to install the native 
ones).  Particularly as an important use case of virtual machines is 
running older distributions which are not updated very much, and which 
might come with a very out-dated version of the Additions.  And yes, we 
do add features from time to time, which users might expect to be able 
to use even with old guest distributions.  And updated versions of e.g. 
VBoxService may depend on updated kernel modules.

Presumably there will be a time when the Debian and Ubuntu versions 
which you are now keeping up-to-date will no longer be actively updated 
but will still have users wanting up-to-date Additions.

>
> sorry for the late reply,

Thank you for the reply.

Regards,

Michael

> thanks
>
> G.
>

-- 
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