Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot distinguish between EGIT_COMMIT and ${PN}_LIVE_COMMIT #5

Open
doctaweeks opened this issue Jun 13, 2018 · 3 comments
Open

Cannot distinguish between EGIT_COMMIT and ${PN}_LIVE_COMMIT #5

doctaweeks opened this issue Jun 13, 2018 · 3 comments

Comments

@doctaweeks
Copy link

It looks like the git-r3 eclass just internally sets EGIT_COMMIT when ${PN}_LIVE_COMMIT is used which means smart-live-rebuild can't distinguish between the two. In the latter case it may/should call out packages for updates as they really are live.

I suspect this is a limitation similar to issue #4.

@mgorny
Copy link
Member

mgorny commented Jun 13, 2018

Actually, I think it's tad different. If you set ${PN}_LIVE_COMMIT in make.conf, then obviously the package is bound to specific commit and there's no point in rebuilding it. If you change it or remove it, it's your responsibility to rebuild the package afterwards.

That said, that *_LIVE_COMMIT thing is backwards-compatibility stuff. Use EGIT_OVERRIDE_* variables instead. S-l-r isn't aware of them at all at the moment, so they will work the way you want them to.

@doctaweeks
Copy link
Author

If you set ${PN}_LIVE_COMMIT in make.conf, then obviously the package is bound to specific commit and there's no point in rebuilding it.

Agreed. However, it could also be used on the command line during isolated testing and a user may still want it called out later when s-l-r is run.

Use EGIT_OVERRIDE_* variables instead.

Thanks. I was not aware of these since they are not in the eclass reference or man pages. Reference for anyone else: https://archives.gentoo.org/gentoo-dev/message/947d684c2632a0208da9cf4704694f3d

@mgorny
Copy link
Member

mgorny commented Jun 13, 2018

Yeah, I need to figure out how to document them properly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants