I've recently been working on updating ebuilds in the tree to build with gecko-sdk rather than with mozilla. It would be really *nice* if this got into portage somehow. ;-) I'll post the new ebuilds here as I edit them. By the way, if this *is* put into portage, the default behavior should be to emerge mozilla-bin and mozilla-firefox-bin as the from-source ebuilds will block gecko-sdk. That's just so there's no cruft floating around on the system, of course.
Created attachment 77599 [details] A virtual for the entire thing, named gecko-0.ebuild This is probably the most important part of this enterprise. It will make defaulting to the binary ebuilds convenient rather than bothersome.
Created attachment 77600 [details] A new ebuild for gecko-sharp which follows the new rules.
Created attachment 77601 [details] A new ebuild for gecko-sdk, adding a PROVIDES="virtual/gecko" line.
Created attachment 77602 [details] A new ebuild for beagle+version bump a-la BUG# 116654 This patch answers comments on BUG# 116654 http://bugs.gentoo.org/show_bug.cgi?id=116654 so please check there as well.
Created attachment 77604 [details] A new ebuild for mozilla, PROVIDES="virtual/gecko", blocked by binary and firefox
Created attachment 77605 [details] A new ebuild for firefox, PROVIDES="virtual/gecko", blocked by binary and mozilla
Created attachment 77606 [details] A new ebuild for mozilla, PROVIDES="virtual/gecko", blocked by binary and firefox Updated to provide the "geckobrowser" virtual to facilitate checking for a gecko-type browser.
Created attachment 77607 [details] A new ebuild for firefox, PROVIDES="virtual/gecko", blocked by binary and mozilla Updated to provide the "geckobrowser" virtual to facilitate checking for a gecko-type browser.
Created attachment 77610 [details] A new ebuild for firefox, PROVIDES="virtual/gecko", blocked by binary and mozilla Woops. I bungled that. This is the *correct* ebuild for mozilla-firefox, adding the PROVIDES="geckobrowser" to facilitate checking for a gecko-type browser.
Created attachment 77611 [details] A new ebuild for mozilla, PROVIDES="virtual/gecko", blocked by binary and firefox Woops. I bungled that. This is the *correct* ebuild for mozilla, adding the PROVIDES="geckobrowser" to facilitate checking for a gecko-type browser.
Created attachment 77612 [details] A new ebuild for mozilla-bin, adding PROVIDE="virtual/geckobrowser"
Created attachment 77613 [details] A new ebuild for mozilla-firefox-bin, adding PROVIDE="virtual/geckobrowser"
Created attachment 77614 [details] List of ebuilds containing "www-client/mozilla" I made a list (via find /usr/portage -path '/usr/portage/metadata' -prune -o -name "*.ebuild" -print0 | xargs -0 grep -l "www-client/mozilla" ) of all the ebuilds that contain the string "www-client/mozilla" to find the ebuilds that should depend on either virtual/gecko or virtual/geckobrowser. This is the list I will be working from, and is also the one I expect will yeild results. If anyone else wants to work on this, feel free. I need to go to bed.
I've been checking around on bugs.mozilla.org, and I have discovered (much to my dismay) that gecko-sdk and the sdk that installs with mozilla-firefox-1.5 are not, in fact, the same thing. So that means a change in tactics is required. It is not possible to embed mozilla-firefox-1.5 due to the fact that the application itself is built statically. The solution is to embed mozilla-1.7 instead. (http://benjamin.smedbergs.us/blog/2005-07-11/xulrunner-short-term-and-mid-term-roadmap/) So. The new plan is to build gecko-sdk when an app needs to embed mozilla (this includes all gecko-type browsers like epiphany, konqueror, galeon, etc...) and *not* to build mozilla or mozilla-firefox by default. Usually, this just means fixing the configure to look for mozilla in a non-standard location (in this case, gecko-sdk). When we want to build mozilla-firefox-1.0.7, it should *not* install any sdk. This will keep the SDK separate and distinct from the application. When we build mozilla-firefox-1.5, we cannot install the SDK at all because the release of this SDK is to be 1.8, when it finally comes out. That said, one small problem exists with the current firefox-bin (1.0.7 and 1.5) in that they are built for gtk1 and freetype2, which is clearly *not* what we want in a modern Gentoo system. This is just a reflection of Mozilla.org's persistence in making backwards-compatible builds for those Linux users who cannot or will not upgrade. So we cannot emerge any mozilla browser onto a system by default, my friends, as it gives one more opportunity for something to break in the future. Here's the plan: Take out the virtual/gecko and have all current ebuilds for apps which embed mozilla depend on net-libs/gecko-sdk. For all ebuilds which produce a gecko browser, we can add PROVIDE="virtual/gecko-browser" to facilitate checking (plugins, etc.) mozilla.eclass needs to be modified a bit so it doesn't install mozilla-launcher when we are building the SDK. We don't need it at all. For that matter, there should be very few USE flags on the gecko-sdk ebuild. As few as possible would be nice, just to prevent confusion. Warn the user that the current build of firefox-bin is not using current software paradigms as a result of Mozilla.org's desire for backwards- compatibility and then suggest the source build if that is not ok. We should also be doing the same for mozilla-bin and thunderbird-bin. The mozilla suite (source) should be considered deprecated in favor of gecko-sdk and each should block the other. The mozilla suite is not undergoing further development right now, while gecko-sdk is. The mozilla ebuild can be modified such that it builds the common files and stores the resultant directory in /usr/src/mozilla or some such. This is a practice supported by Mozilla.org. Gecko-SDK can then be built and emerged from this, as can the Mozilla Suite, Firefox, Thunderbird, and Sunbird. What this would mean is setting up a virtual like virtual/mozilla-source to build the common files and install them to /usr/src/mozilla, and then have each of the branches depend on this virtual (gecko-sdk, mozilla, mozilla-firefox, etc.) so that when one is built, they all receive a reduction in build time. The exception is, of course, mozilla-firefox-1.5, which depends on a different codebase. That's the plan I intend to follow, folks. Any help from people who know the ebuild system better than I do is much appreciated (and that's just about anyone, but I do try). Here are some references I will be working from: http://www.mozilla.org/build/distribution.html http://developer.mozilla.org/en/docs/Mozilla_Build_FAQ http://developer.mozilla.org/en/docs/Configuring_Build_Options (Specifically, Building multiple applications from the same source tree)
I am still working on this bug, just so everyone knows. Right now I am working on consolidating the ebuilds for firefox and thunderbird, moving the common configuration stuff into mozconfig.eclass, setting up a new function in mozilla.eclass to create a new mozconfig file for thunderbird and firefox (but they both use the same common .mozconfig), updating the gecko-sdk ebuild so it builds the common components, merges the sdk, and *then* tarballs the source directory as-is. This will reduce compilation times when someone wants to compile either firefox or thunderbird. The new firefox and thunderbird ebuilds will depend on mozilla-source to ensure the source gets built, and gecko-sdk will provide mozilla-source. This way, one will have the sdk separate from the mozilla builds and yet benefit from its compilation by having reduced build times. I've also done more research. It appears that when the mozilla-1.8 base is released stable, it will be the development platform for firefox-1.5 and thunderbird-1.5. The current firefox-1.5 is *unstable* and should not be used currently as the sdk has not gelled yet. It will soon, though. The nice part about this method is it doesn't need to be changed when mozilla-1.8 rolls around - it will still build all components as usual.
This is too much of a change to current tree. If you want to see anything of this nature you should first think about discussing it on dev mailing list. As far as your reasoning goes I do not follow, maybe it is me.
Wait, wait, wait a minute. It's not really as much of a change as it might seem here. Everything is essentially transparent - all past ebuilds end up working correctly without changes. It's just that the *new version* does things a bit differently. And it *has* to change at some point because the new Mozilla-1.8 tree is incompatible with the Mozilla-1.7 tree - the way it is now will allow mixing gecko-sdk-1.7 with mozilla-1.8, which is not right at all and can cause problems in the future. (And epiphany acually builds against gecko-sdk, even if in an incorrect manner.) For that matter, if someone wants to build something against mozilla, and he or she has firefox installed, they would have to download *another* source tarball and recompile, which is completely unneccessary - the mozilla-1.7 source tarball contains everything needed. No real changes to the tree are necessary - this is a matter of a new *version* not a rearrangement of what we currently have. And as for discussing this on the dev list first - I am a college student. I simply do not have the time for a lengthy discussion on this. The idea was to present my ideas here for discussion. It may have been a bit outside the norm, but it was necessary.
