Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 119630

Summary: Convert to gecko-sdk for ebuilds
Product: Gentoo Linux Reporter: Ryan Egesdahl <regesdahl>
Component: New packagesAssignee: Mozilla Gentoo Team <mozilla>
Status: RESOLVED INVALID    
Severity: enhancement    
Priority: High    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Attachments: A virtual for the entire thing, named gecko-0.ebuild
A new ebuild for gecko-sharp which follows the new rules.
A new ebuild for gecko-sdk, adding a PROVIDES="virtual/gecko" line.
A new ebuild for beagle+version bump a-la BUG# 116654
A new ebuild for mozilla, PROVIDES="virtual/gecko", blocked by binary and firefox
A new ebuild for firefox, PROVIDES="virtual/gecko", blocked by binary and mozilla
A new ebuild for mozilla, PROVIDES="virtual/gecko", blocked by binary and firefox
A new ebuild for firefox, PROVIDES="virtual/gecko", blocked by binary and mozilla
A new ebuild for firefox, PROVIDES="virtual/gecko", blocked by binary and mozilla
A new ebuild for mozilla, PROVIDES="virtual/gecko", blocked by binary and firefox
A new ebuild for mozilla-bin, adding PROVIDE="virtual/geckobrowser"
A new ebuild for mozilla-firefox-bin, adding PROVIDE="virtual/geckobrowser"
List of ebuilds containing "www-client/mozilla"

Description Ryan Egesdahl 2006-01-19 18:37:30 UTC
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.
Comment 1 Ryan Egesdahl 2006-01-19 18:39:52 UTC
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.
Comment 2 Ryan Egesdahl 2006-01-19 18:40:59 UTC
Created attachment 77600 [details]
A new ebuild for gecko-sharp which follows the new rules.
Comment 3 Ryan Egesdahl 2006-01-19 18:41:54 UTC
Created attachment 77601 [details]
A new ebuild for gecko-sdk, adding a PROVIDES="virtual/gecko" line.
Comment 4 Ryan Egesdahl 2006-01-19 18:45:27 UTC
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.
Comment 5 Ryan Egesdahl 2006-01-19 18:51:13 UTC
Created attachment 77604 [details]
A new ebuild for mozilla, PROVIDES="virtual/gecko", blocked by binary and firefox
Comment 6 Ryan Egesdahl 2006-01-19 18:53:48 UTC
Created attachment 77605 [details]
A new ebuild for firefox, PROVIDES="virtual/gecko", blocked by binary and mozilla
Comment 7 Ryan Egesdahl 2006-01-19 19:37:34 UTC
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.
Comment 8 Ryan Egesdahl 2006-01-19 19:38:33 UTC
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.
Comment 9 Ryan Egesdahl 2006-01-19 19:45:48 UTC
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.
Comment 10 Ryan Egesdahl 2006-01-19 19:47:07 UTC
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.
Comment 11 Ryan Egesdahl 2006-01-19 19:52:58 UTC
Created attachment 77612 [details]
A new ebuild for mozilla-bin, adding PROVIDE="virtual/geckobrowser"
Comment 12 Ryan Egesdahl 2006-01-19 19:55:51 UTC
Created attachment 77613 [details]
A new ebuild for mozilla-firefox-bin, adding PROVIDE="virtual/geckobrowser"
Comment 13 Ryan Egesdahl 2006-01-19 20:01:21 UTC
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.
Comment 14 Ryan Egesdahl 2006-01-21 11:01:11 UTC
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)
Comment 15 Ryan Egesdahl 2006-01-25 17:34:32 UTC
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.
Comment 16 Jory A. Pratt 2006-01-25 21:59:21 UTC
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.
Comment 17 Ryan Egesdahl 2006-01-27 12:18:22 UTC
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.