[vbox-dev] Co-existence of distribution-installed Guest Additions and Oracle-provided ones

[Gianfranco Costamagna]

Hello Michael

>
"Ack" as in something you are likely to implement when you have time?


sure, maybe not for 5.1.24 or whatever, but for a 5.2 or so
(this is because I don't want to SRU this change into a stable ubuntu release,
specially because I have no idea about a possible implementation in detail)
and neither I want to maintain such a delta in case of CVE or new minor releases
>That will work well if the kernel package is updated relatively
>frequently, which is probably the case.


yes, modulo me forgetting to prod them :)

(you can email apw in case you want them to be merged and he will take care in a few minutes)
>> 4.1.44 Lucid
>> 4.3.36 Trusty/Vivid
>> 5.0.40 Xenial
>> 5.1.22 Zesty/Artful.
>From my point of view it would maked  most sense to always track the most
>recent stable release.  4.1.44 for example is long out of support, and
>we try to make sure that any supported Additions version will work with
>any supported version of VirtualBox, so 5.1 Additions should work with
>VirtualBox 5.0.  We do not test this extensively, but we would take bug
>reports against it (I don't think there has ever been one).  And of
>course, there is no logical requirement for you to package the same
>version (even major version) of VirtualBox, the main (host) software and
>of the Guest Additions.  Whether that makes sense from a Debian/Ubuntu
>policy point of view is another question of course.


switching qt to 5, python to 3, new dependencies, and so on (old toolchains and a lot
of untested environments...) no please :p

I prefer to ask people to update to a new Ubuntu release or use my ppa (where I backport
the latest and greatest one)

except for Ubuntu Precise that has 4.1.x (released 5 years ago and now EOL, so I can't update
it anymore since the archive is closed and dead already), every supported Ubuntu release
has the latest 4.3.x, 5.0.x or 5.1.x and they seems to be still maintained all of them)

I might bump 4.3.36 to 4.3.40, but seems not worth the effort :)

5.0 and 5.1 seems to fit for now your release schedule, even if they might reach an EOL
point in the near future :/

>And while we are on the subject, is it worth looking at things that we
>(the team at Oracle) could do to make the Additions easier to package?
>That also extends to the main software to some extent, as our Linux
>packaging is one of the too many things I am involved in.


I don't know, an upstream build system might be nice to have.
For now we have two guest-packages

the virtualbox-guest-{utils,dkms,x11} that are built on top of the virtualbox source code
and the virtualbox-guest-additions-iso that is your iso image bit-bit identical and downloaded
from the download repository.

If you mean the iso file, I don't see how can you improve my build process, since I just
copy-paste it into the correct directory :)


so, to sum up, can we define some pseudo code to make a backward compatible change for this issue?

e.g.
if your-file-exist then
exit and not install the guest-* stuff
maybe print an error message quoting some "uninstall official guest stuff guide"


if your-file-doesn't-exist then
I don't know if an older version is installed or not, so install it anyway


install *always* the guest-additions-iso iso file, because the script called for installation is
already completely under your control.

under your script:
if no script exists, install
if dpkg -l returns an ubuntu installation then ask to remove it and exit

dpkg -l *can't* return the guest-additions-iso installed, because installed in the host, not guest :p

does this sounds right?


from your perspective checking if the dpkg package is installed is easier, from my side some more tricky :)

G.