Bugzilla Bug 221105

Google Earth for Linux version 4.3 available at
http://dl.google.com/earth/client/current/GoogleEarthLinux.bin

Please also see bug #219387 where this issue was improperly fixed.

Created an attachment (id=157391) [details]
x11-misc/googleearth-4.3.7204.836.ebuild

Ebuild is just a quick hack from the one already included in portage. Don't
know why, on one of my Gentoo installation (with X, KDE and stuff like that) it
didn't work with "missing libXinerama.so.1.0.0". Will check that later today.

(In reply to comment #2)
> Created an attachment (id=157391) [edit] [details]
> x11-misc/googleearth-4.3.7204.836.ebuild
> 
> Ebuild is just a quick hack from the one already included in portage. Don't
> know why, on one of my Gentoo installation (with X, KDE and stuff like that) it
> didn't work with "missing libXinerama.so.1.0.0". Will check that later today.
> 

Thank you for the ebuild.  This seems to be the standard way of getting updates
these days.

*** Bug 231608 has been marked as a duplicate of this bug. ***

Nice how a perfectly functional ebuild has languished for a month without a
commit to portage.

I think this is the current Gentoo way of saying, "Welcome.  Please enjoy your
(limited) stay.

*** Bug 232214 has been marked as a duplicate of this bug. ***

Is there anything which could be done about this?  At the moment it is
impossible to install Google Earth at all, so it is unusable if you're not so
lucky that you're having an earlier version installed already.

This version is tagged "stable" in portage, but IMHO that's inappropriate for
something that doesn't even install.  I also think that the severity of this
bug should be "major" because I think it's a "major loss of function" to be not
able to install and use this package.  (See also bug 232214 and bug 232419.)

I know about the problem with the unversioned download link, but is there
nothing which could be done about that?  Wouldn't it suffice to write a small
script which regularily checks that site and sends an email to the maintainer
in case the download changes?

do you know whether its really prohibited that we put the binary into gentoo
mirrors? i didn't see such exact clause in license.

Why has this ebuild not yet been put into the Portage tree?

I would be happy to maintain this package, if needed. It would certainly appear
that no-one else wants to maintain it, yet plenty of people would like to see
it in Portage.

bump

*** Bug 233656 has been marked as a duplicate of this bug. ***

(In reply to comment #9)
> Why has this ebuild not yet been put into the Portage tree?
> 

The maintainer is currently away. I've sent an email to gentoo-core, if anyone
is willing to pick this up. Apparantly not.


(In reply to comment #11)
> bump
> 

When I see such silly comments popping up as spam in my inbox for packages I do
maintain, my reaction likely is to ignore the respective bug for the next two
weeks.

*** Bug 233746 has been marked as a duplicate of this bug. ***

Yes, no-version-"source" sucks, but we will have to live with it for some
time...

I have included the above ebuild in my personal overlay:
https://svn.tar.bz/repos/pkalin/trunk/README.txt

Feel free to use it.

I have updated the Manifest to the new version, so you have to delete the old
GoogleEarthLinux.bin in ${DISTDIR} first, otherwise it will not emerge.

BTW, the new version seems _very_ fast to scroll on my laptop, it used to crawl
(even when bitmaps were cached).

If I had time, I'd pursue this further because I hate people who complain but
don't offer to help, but I simply don't have time right now. What little time I
did spend on this revealed something that might help a little. There are
versioned links to the downloads. It won't help when a minor minor version
update is released, eg 4.2.2 to 4.2.3, but should help avoid problems when a
minor version update is released, eg 4.2 to 4.3.
http://dl.google.com/earth/client/GE4/release_4_2/GoogleEarthLinux.bin
http://dl.google.com/earth/client/GE4/release_4_3/GoogleEarthLinux.bin

Using those links could also allow leaving the 4.2 ebuild in portage (though it
would need to be edited to use the new link), and put in a new ebuild for 4.3.
I hope this helps someone qualified to update portage.

Thank you Daniel, as a starter, see below.

------------------------------------------------------------------------
r274 | Kalin.KOZHUHAROV | 2008-08-06 11:14:55 +0900 (Wed, 06 Aug 2008) | 19
lines

Trying to incorporate the idea form comment #16 (bug #221105)...

The problem:
        Google only provides one SRC_URI per major release which maps to the
        latest source in that major branch, so it often changes making it
        impossible to have stable ebuild...

The solution:
        Ask Google to stop doing that and have SRC_URIs with version info
        inside

The workaround:
        This ebuild has a workaround which checks the version inside the source
        package end bails if there is no match. Unfortunately it turns
        RESTRICT="fetch" which makes it difficult to use...

Apparently Google has bumped the current 4.3 release to 4.3.7284.3916,
so I updated the ebuild. Will update the 4.2 release as well.

------------------------------------------------------------------------
[pkalin overlay] https://svn.tar.bz/repos/pkalin/trunk/README.txt

Thanks Daniel for finding the somewhat-versioned download links. At least there
can now be a stable ebuild for 4.2 that is unlikely to keep breaking, as well
as a 4.3 ebuild that will keep needing to be renamed until the 4.4 series comes
out.

Thanks also Kalin for posting your ideas, though I'm sticking with the existing
non-fetch-restricted strategy for now.