Summary: | svn, cvs eclasses should ELOG their checked-out version | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Tanktalus |
Component: | Eclasses | Assignee: | No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it <maintainer-needed> |
Status: | RESOLVED OBSOLETE | ||
Severity: | enhancement | CC: | arfrever, hattya, mgorny, sping, vapier |
Priority: | High | ||
Version: | 2008.0 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Tanktalus
2009-03-10 18:28:59 UTC
Ok in svn it might have reason, but are you sure that for user is anyhow meaningfull the git hash which is used for revision? No problem in me if users really want it it is really trivial to add it. I'm assured by the upstream for, as an example, xf86-video-radeonhd, that it would be useful in my bug reports when I'm using their dev tree (the 9999* ebuilds). If it makes it into my ELOG email, then I can be sure of what level I'm running. I suppose that if you can (optionally?) log as much detail about it as possible, that's great, too (what branch, URL, etc.), as it can remove all doubt about what I'm running. e.g., Note: You are running PRERELEASE software. Don't file a gentoo bug if this doesn't work, but instead file a bug and refer to the following build level: git://anongit/freedesktop.org/git/xorg/driver/xf86-video-radeonhd branch: master git level: 0x1234556.... (whatever it is) Or something like that. I'm not a git expert, so I don't really understand what all might be important in there, but hopefully you get the giSt of it. :-) Thanks! Ok i am convinced and i will work on it in x11 overlay. :] Dont expect it hit main tree soon, i think it have 3 more weeks of testing in x11 (4 weeks per major eclass change i have as rule :P) but it will be there waiting for ya nicely packed i guess on sunday evening :P If you trigger a rebuild of a set (e.g. @kde-live) which includes many ebuilds, all of them are rebuilt even if only a small subset has been changed. If the sources of a specific ebuild in the set have not changed, this ebuild could be skipped Something like: - get latest revision number from repository - check revision number of current version in /usr/portage/distfiles/{git/svn}-src - if same, and module was successfully built with that revision, skip rebuild of module and continue with next module from the set git eclass in x11 overlay now elog requested informations. Will the same information be elog'd for SVN, too? The git information has already proved useful in upstream bug reports, and I've had more than one need for the svn commit level. Thanks, In case of subversion.eclass, somebody should attach a patch for review. Does this bug still apply? Now every major VCS eclass exports the checked out revision or some other identifier into environment.bz2. (In reply to comment #4) > - get latest revision number from repository > - check revision number of current version in > /usr/portage/distfiles/{git/svn}-src > - if same, and module was successfully built with that revision, skip rebuild > of module and continue with next module from the set Markus, you may want to take a look at app-portage/smart-live-rebuild. (In reply to comment #8) > Does this bug still apply? Now every major VCS eclass exports the checked out > revision or some other identifier into environment.bz2. > > (In reply to comment #4) > > - get latest revision number from repository > > - check revision number of current version in > > /usr/portage/distfiles/{git/svn}-src > > - if same, and module was successfully built with that revision, skip rebuild > > of module and continue with next module from the set > > Markus, you may want to take a look at app-portage/smart-live-rebuild. |