Bugzilla Bug 189827

Google earth 4.2 is released. Note the new download URL.

(In reply to comment #0)
> Note the new download URL.

I note long-lasting retarded unversioned file name that keeps breaking
manifests over and over again.

yes Jacub, so bad...we can just manage this by using the googleearth autoupdate
function...it's really a pain..

anyone already asked google for that?

I do not believe anyone has gotten a real answer from google about this. The
more people complain, the better.


Anyway I have changed the uri and redigestet the ebuild. Thanks.

Stefan, why you keep the version 4? isn't better to change the version to
4.2.xxx as from binary?

the binary has no version and it still has the big 4 so its correct

the binary file name has no version, but if you ask for "about" you have it.

like this you cannot make people bump, as the should just rebuild the
package...

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

Ok same problem as in #191039. How you name the ebuild isn't really google's
business, isn't it? ;)

@"the binary has the big 4":
For example, the openoffice splash also shows "2.2" and still the ebuild is
named "2.2.1".

Also, the handbook says [1]:
> Package revision numbers should be incremented by Gentoo Linux developers
> when the ebuild has changed to the point where users would want to upgrade.
> Typically, this is the case when fixes are made to an ebuild that affect the 
> resultant installed files, but the ebuild uses the same source tarball as the 
> previous release.

IMHO a new version is "the point where users would want to upgrade", so
shouldn't you at least name the ebuild googleearth-4_r1 or so?

[1] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1

Hi Phillip,

I can understand you, but there is a little problem:

Imagine we would bump x11-misc/googleearth to 4-r1 and adjust the new checksum
accordingly, what shall we do with 4? This eBuild wouldn't be useful anymore in
any case, because we do not have the old 4.0 installation file (with the old
checksum) anymore, so adding -r1 and removing 4 is not the best solution.

On the other hand, and I agree with you here, it would be a the simpliest way
to let users upgrade to 4.2.

Thus I would also request a 4.2 eBuild and delete the old 4 one. Revisions are
have, at least as I see it, a slightly other goal that would not be triggered
here (because we speak about a really new (program) version, and not minor
changes in the eBuild or whatsoever.)

Also, removing 4 when having 4.2 is more understandable then a standalone 4-r1
eBuild, IMHO. (In my opinion, if adding a revision you must also keep the
original version and all other [old] revisions as well.)

-Ionic

yes, google release always with that same file name but the version inside the
binary is always different 4.2.x.y.z

so the old ebuilds should be deleted and the one with 4.2.x.y.z version added.
i understand it's not a really confortable solution for a mainteiner, but it's
the best way to keep it working and clear to users, ihmo.

my 2 cents

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

Here's a direct URL to 4.2 I found via google:
http://dl.google.com/earth/client/GE4/release2/GoogleEarthLinux.bin
(Via http://earth.google.com/support/bin/answer.py?hl=en&answer=68021)

I guess they will take it offline when a new version is released, but at least
it's a version specific URL.