app-emulation/virtualbox-4.0.0 (version bump) Reproducible: Always Steps to Reproduce:
Created attachment 257957 [details] virtualbox-4-config
Created attachment 257959 [details] virtualbox-4-localconfig
Created attachment 257961 [details, diff] patch
Created attachment 257962 [details, diff] patch
Created attachment 257964 [details, diff] patch
*** This bug has been marked as a duplicate of bug 349407 ***
changes from 3.2.12: - name change from virtualbox-ose to virtualbox - MY_P and S naming logic - remove the enabling by default for the 'additions' use flag (VirtualBox is able to download and mount the iso from the GUI) - new use flags: 'doc' (builds the pdf manual) and 'java' (controls the java bindings) - added blocker on app-emulation/virtualbox-ose - removed extra RDEPEND section. One is enough. - ordered the RDEPEND and DEPEND items alphabetically - removed QA_TEXTRELS_x86 because I don't see the point of having such a long file list in an ebuild (the paths have changed,in case someone wants to bring it back) - removed the as-needed patch because it's no longer needed - upgraded the other patches manually - injected the user's CFLAGS and CXXFLAGS into the build process - removed the flag stripping because it works fine with my crazy CFLAGS - removed some deprecated elog messages Tested on ~x86 with Windows XP and OS X guests. Testers needed for: - ~amd64 - the 'headless' and 'pulseaudio' use flags
reopening the bug because the ebuilds differ and I don't think that mixing patches with the other attempt helps anyone
First of all thanks for your work :) Secondly, no, this bug is a complete dupe and I don't want to have the whole virtualbox-4 stuff spread across several bugs in bugzilla. Please join the other bug in adding your changes. I didn't find an ebuild attached here so I couldn't add the useful changes you seem to have made to the work-in-progress ebuild I currently have in my private overlay (see bug #349407). Although I disagree with some of the changes you proposed here: The additions USE flag will stay because that way the additions are globally available for every user on a machine so not every user has to download the additions on his own. The QA_TEXTRELS_x86 will stay until someone can tell me good reasons to not keep them anymore. The asneeded patch is still necessary for people with forced asneeded compiler (see bug #349407#c11). It even needs more work for vbox-4 as they added some more annoyances. On the other hand I'd be very interested in your changes to make java optional as well as the flag filtering cleanup. Please be so kind and attach your changes as patch of the ebuild currently existing in my overlay in the bug I marked this one as dupe of. *** This bug has been marked as a duplicate of bug 349407 ***
Created attachment 257966 [details] ebuild
My bad, forgot to upload the most important file - the ebuild itself :-) I'll take a second look at the as-needed patch, but other than that I'm not willing to compromise on the quality of this ebuild. Please take whatever you want from it, but leave this bug as a way for me to provide a Gentoo-style optimized virtualbox package to whoever is interested. It's OK if it doesn't make it in the main repo. Thanks.
Please don't think I don't appreciate your work. You did some valuable changes which I simply forgot or thought it wouldn't be possible to implement. On the other hand it's totally counterproductive if we keep several bugs with different ebuilds open. I think we should combine all good stuff from all ebuilds which are floating around. But the best way to achieve this is via a single bug entry where all changes are centrally accessible. So once again, please join us in the other bug.
Here's where I come from: as a user browsing bugzilla for ebuilds not available in the main repo, I expect to find the entire ebuild along with the needed files to download and place in my local repo. After that it's just a matter of creating the manifest and emerging. What you are doing when you request ebuild diffs from an ebuild in your own public repository takes the users out of the equation. The bug is useful only to you and the people closely involved. I'm not willing to invest my time in that. Even if the model changes, what's the point in adding my 6 files to a bug that already has 5 unrelated files uploaded to it? Nobody would know which file is required by which ebuild. Not to mention the fact that I dropped 'ose' from the package names and that affects the dependencies. You misunderstood my change to the 'additions' use flag, BTW. I just dropped the plus sign so it's not enabled by default.
