Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 383761 - git-2.eclass should use git.eclass's default EGIT_DIR when appropriate
Summary: git-2.eclass should use git.eclass's default EGIT_DIR when appropriate
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Donnie Berkholz (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-20 05:51 UTC by Alexandre Rostovtsev (RETIRED)
Modified: 2011-09-23 14:02 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
patch to use git.eclass's default EGIT_DIR when appropriate (git-2.eclass-EGIT_DIR-compat.patch,895 bytes, patch)
2011-09-20 05:51 UTC, Alexandre Rostovtsev (RETIRED)
Details | Diff
Try to migrate git.eclass checkouts to the new eclass. (Try-to-migrate-giteclass-checkouts-to-the-new-ecla.patch,1.16 KB, patch)
2011-09-20 14:42 UTC, Michał Górny
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alexandre Rostovtsev (RETIRED) gentoo-dev 2011-09-20 05:51:32 UTC
Created attachment 287109 [details, diff]
patch to use git.eclass's default EGIT_DIR when appropriate

(as discussed in #gentoo-desktop)

One highly annoying factor in migrating from git.eclass to git-2.eclass is that the git repositories which git.eclass, by default, stores under ${DISTDIR}/git-src, all have to be redownloaded to new directories under ${DISTDIR}/egit-src.

It would be much more logical if git-2's algorithm for setting EGIT_DIR was instead the following:

 if EGIT_DIR is not set
 and git.eclass's default EGIT_DIR exists (i.e. the ebuild had previously used
  git.eclass)
 and git-2.eclass's default EGIT_DIR does *not* exist (i.e. either the ebuild
  had not previously been upgraded to use git-2.eclass, or the user had not
  had the chance to download the sources to ${DISTDIR}/egit-src)
 then set EGIT_DIR to the default git.eclass value.

The attached patch does so.
Comment 1 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2011-09-20 08:45:59 UTC
Tomas, what was the rationale for moving EGIT_DIR?

As I see it, this looks like crawling back. As I see it, we should just use one EGIT_DIR location and:
- if checkout in both new and old location exists, rm -r the old one;
- if checkout exists only in old location, mv or git clone it (the latter should be safer if the checkout can be broken somehow).

I like the 'git-src' location more, to be honest but it is likely that 'egit-src' has now newer checkouts, so switching back would result in re-downloading new commits.
Comment 2 Tomáš Chvátal (RETIRED) gentoo-dev 2011-09-20 09:21:38 UTC
As i wrote multiple times this bug was WONTFIX.
And i explained it on -dev mailing list and on bugs, just search it.

It failed to work on some checkout done by old git.eclass, so the directory was renamed, if users trust that the git thingu won't fail for them they are free to move that clone thir themselves, but the eclass should not do it.

But if donnie wants to mess with it and implement moving the directories in the eclass he should rather mv git-src/something egit-src/something prior the update rather than working in the old location anyway.
Comment 3 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2011-09-20 14:42:27 UTC
Created attachment 287167 [details, diff]
Try to migrate git.eclass checkouts to the new eclass.
Comment 4 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2011-09-20 14:46:33 UTC
(In reply to comment #3)
> Created attachment 287167 [details, diff]
> Try to migrate git.eclass checkouts to the new eclass.

This is my suggestion. It is very simple -- on initial checkout tries to find the old clone using the same rules as ol' git.eclass. If it does find one, it prepends it to EGIT_REPO_URI.

Thus, the eclass will first try to clone the old clone. If it fails, it will fallback to fetching from remote. This should be a pretty safe way. One disadvantage it has is that the package needs to emerged again to fetch changes from remote but I think it's basically one-time issue not worth addressing.

If we go further this way, I can prepare a patch to remove old git-src clones.
Comment 5 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2011-09-23 12:13:53 UTC
The patches have been sent to gentoo-dev for review already and should be in tree soon.
Comment 6 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2011-09-23 14:02:05 UTC
Ok, should be fixed now. Feedback appreciated.