Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 339939 - repoman cannot distinguish between 'live' source or tagged source when using git
Summary: repoman cannot distinguish between 'live' source or tagged source when using git
Status: RESOLVED CANTFIX
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Repoman (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Portage team
URL: http://archives.gentoo.org/gentoo-dev...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-06 13:33 UTC by Mike Pagano
Modified: 2011-06-17 19:03 UTC (History)
1 user (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Pagano gentoo-dev 2010-10-06 13:33:42 UTC
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?
Comment 1 Jeremy Olexa (darkside) (RETIRED) archtester gentoo-dev Security 2010-10-06 13:45:52 UTC
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 ;)
Comment 2 Mike Pagano gentoo-dev 2010-10-06 14:30:38 UTC
Thanks, Jeremy. These are good points to consider. 

It was nice and "easy" (lazy), using the git tags, though. :)
Comment 3 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2010-10-06 17:19:23 UTC
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.
Comment 4 Zac Medico gentoo-dev 2010-10-06 18:22:44 UTC
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
Comment 5 Zac Medico gentoo-dev 2010-10-07 19:47:52 UTC
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
Comment 6 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2010-10-07 19:52:05 UTC
(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.
Comment 8 Mike Pagano gentoo-dev 2010-10-07 20:14:09 UTC
(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
Comment 9 Jeremy Olexa (darkside) (RETIRED) archtester gentoo-dev Security 2010-10-07 20:26:00 UTC
(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.