[vbox-dev] VirtualBox-OSE tarball

[Klaus Espenlaub]

Till Maas wrote:
> Hiyas,
> 
> is it possible to get an URL to the VirtualBox-OSE tarball, that is not
> redirected to an URL that has (changing) GET parameters? Currently there is
> a h parameter, that always changes. This makes it harder to automatically
> fetch the tarball when I increase the version in a rpm spec file.

Sorry to put it so bluntly - but the only way we could possibly fix this 
issue would be to remove this download. I'm sure no one likes that 
option. The automatic generation of the redirection URL is due to the 
way US export control is handled on the web server handling the 
downloads. That's the price of reinstating the direct download links. 
Sun is a US company and thus has to follow US legislation in this area.

It's rather interesting that in the time where there were no direct 
download links we got less complaints about the lack of them than now 
about this behavior which just requires another option to wget or maybe 
2-3 additional lines in a shell script. Nothing compared to the effort 
we spent and still spend on having this much easier download option.

> Also the naming scheme of the tarball and the directory inside the tarball
> changes every now and then. Maybe it has settled the last releases, because
> I did not download every release of the 1.6.x branch. Please keep this the
> same. E.g. use from now on VirtualBox-$VERSION-OSE.tar.bz2.

That really was the case with each and every release since 1.6.0 (I 
didn't check older releases but I think they had the same scheme). I 
really fail to understand what the issue is.

> And the last favour I want to ask for, is to provide a tarball that does not
> contain precompiled binaries and copies of other system libs.

I'll comment after each suggestion.

> Currently after untarring, it seems that half of the contents can be
> removed:
> 
> 28M     tools/

Stripping them out will cripple the source package - some of these 
binaries are vital for building VirtualBox, and are either modified or 
otherwise less than trivial to get. Splitting those out per build 
platform is a waste of time with very little benefit. I think everyone 
would prefer us to work on more important things.

> 47M     src/libs/

Part of this is actually a legal requirement for meeting LGPL and other 
licensing conditions. And other parts are heavily modified libraries or 
libraries which need to be built in exactly the provided version on 
certain platforms. So removing this would have legal and functionality 
implications or even break building.

> 18M     kBuild/bin/

That's required to get VirtualBox building reliably. You can't mix and 
match arbitrary kBuild tool versions and VirtualBox source trees. Also 
adding kBuild to the list of things you have to do before even thinking 
about building VirtualBox is something we'd rather avoid.

> 91M     total

So eliminating those 91MB (out of roughly 171MB) seems attractive but in 
fact is counter-productive. You'd get an unbuildable source tree - at 
least following the build instructions. The list of build dependencies 
would explode, and we'd have to write lots of additional build instructions.

This might sound bad news for people following a "everything from 
source" policy, but they can ignore those binaries and do it the hard 
way. But we kindly ask distributions going this route to test the 
resulting package properly, as really anything can happen due to the 
large deviation from the expected code base - and it would be a waste of 
Sun developer time to even look into such problem reports. Please mark 
such builds clearly and provide your own support contacts where the 
users of this package can actually find them without being wizards. 
There's nothing wrong with asking us for help after it's verified that 
the bug is actually in the Sun-provided code base.

Regards,

Klaus