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 _______________________________________________ vbox-dev mailing list [email protected] http://vbox.innotek.de/mailman/listinfo/vbox-dev
