| Summary: | repoman cannot distinguish between 'live' source or tagged source when using git | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Mike Pagano <mpagano> |
| Component: | Repoman | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED CANTFIX | ||
| Severity: | normal | CC: | darkside |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://archives.gentoo.org/gentoo-dev/msg_64b83155637bcad67478e2d2af276780.xml | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
Tagged or not, there are a whole bunch of reasons why you don't want to use git:// only for a SRC_URI. Here are a few: a) firewalls that block the git port and only allow http (corporate firewalls usually, I have experience with this =P ) b) if mpagano.com goes down, the ebuild is broken c) the distfiles are not mirrored repoman is correct here, in my opinion, but I'm not on the portage team ;) Thanks, Jeremy. These are good points to consider. It was nice and "easy" (lazy), using the git tags, though. :) One more point to consider: the Manifest file doesn't contain the source checksum, thus PM is unable to check whether the source was fetched correctly. Thus, clean keywording does no longer work. If we had some metadata to identify live ebuilds then that would help. For example, I've proposed a PROPERTIES=live setting here: http://archives.gentoo.org/gentoo-dev/msg_64b83155637bcad67478e2d2af276780.xml Here's a quick fix that checks for a EGIT_COMMIT variable definition. http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=abb7c534eee48795354ae3ab1b17ef319bf5e6e3 (In reply to comment #5) > Here's a quick fix that checks for a EGIT_COMMIT variable definition. This is not a fix. It is only a workaround. A workaround which works around a perfectly correct check. I think before implementing such a thing we should discuss the idea of keywording half-live ebuilds a little more. Ok, reverted: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=232593387c394f325b816c93fa09264c4591c3ca (In reply to comment #5) > Here's a quick fix that checks for a EGIT_COMMIT variable definition. > > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=abb7c534eee48795354ae3ab1b17ef319bf5e6e3 > Thanks, Zac (In reply to comment #5) > Here's a quick fix that checks for a EGIT_COMMIT variable definition. > > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=abb7c534eee48795354ae3ab1b17ef319bf5e6e3 > Bad idea, did you read comment #1? :) I guess, it is good that it is reverted already, ha. |
Portpeek source comes from my git repository, therefore I inherit git.eclass. But I properly tag my releases in git. Repoman assumes that it is a live ebuild because of that inherit and throws: LIVEVCS.unmasked 1 This forces me to put this ebuild in package.mask. I believe because of this code in repoman: live_eclasses = frozenset([ "bzr", "cvs", "darcs", "git", "mercurial", "subversion", "tla", ]) ... live_ebuild = live_eclasses.intersection(inherited) Can repoman somehow be modified so that git tagged releases are valid and not 'live' so I don't have to put these versions in package.mask?