| Summary: | x11-misc/googleearth-4.2 version bump | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Sebastian Biallas <gentoo-bugs.5.sepp> |
| Component: | New packages | Assignee: | Stefan Schweizer (RETIRED) <genstef> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | ahbritto, algardas, betelgeuse, gentoo, ionic, patrizio.bassi, phillip.berndt |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://dl.google.com/earth/client/current/GoogleEarthLinux.bin | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Sebastian Biallas
2007-08-22 12:39:54 UTC
(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. |
