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

[Gianfranco Costamagna]

Hi Michael,

(sending again because the Debian address is not allowed to post)

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

/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


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

(BTW there is also the arch maintainer)

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

sorry for the late reply,

thanks


G.