[vbox-dev] (no subject)

Klaus Espenlaub klaus.espenlaub at oracle.com
Tue Jun 24 17:05:54 UTC 2014


On 20.06.2014 14:12, Jon Seymour wrote:
> On 16.06.2014 17:12, Jon Seymour wrote:
>> G'day,
>> Had a quick look (not very detailed), and generally it looks good.
> Thanks for the review.
>>> Not terribly convinced that line 32 in the Dockerfile is the ideal solution:
>>> RUN bash -c 'ln -sf $(cd /usr/src; ls -d linux-headers-*-generic | tail
>>> -1) /usr/src/linux'
>> This looks very much like a hack for me. I can see that on a generic
>> build environment there's little point in depending on the running
>> kernel's version, but such symlinks can be causing other trouble.
>> Setting the KERN_DIR env variable sounds like the clean solution to me.
> Is your concern that I am configuring a symlink or how I am deriving
> the target of the symlink?

The former. Don't think you have many other options than building the 
kernel module for the newest installed kernel (which this hopefully 
picks), except not building one at all and leaving that to the package 
install time. Hard to predict what fraction of the package users has a 
kernel which is the same as at the package build time. If the percentage 
is low then it's a waste of CPU time and disk space to bother about 
shipping binaries.

> I agree with the principle that, in general, one shouldn't be setting
> a symlink of this kind to configure a particular build, although for a
> container-based build environment this seems safe-enough - the
> container isn't going to be used for anything other than building
> VirtualBox. That said, no harm following best practice everywhere.
> If you have suggestions about the best way to derive the value of the
> KERN_DIR variable, I am all ears.

As I said above, the value is probably hard to improve.

> jon.
> Klaus
>> Regards,
>> jon seymour.

More information about the vbox-dev mailing list