[vbox-dev] VirtualBox-OSE tarball
Klaus.Espenlaub at Sun.COM
Tue Sep 23 15:31:14 PDT 2008
Till Maas wrote:
> 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
> 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.
More information about the vbox-dev