Wishlist: Exporting shell variable containing revision requested from GIT/SVN actually leads to grabbing that revision from SVN/GIT with no ebuild changes. Reproducible: Sometimes Steps to Reproduce: 1. Tried REV="r39584" to check out kde4 2. Laughed, and opened Konq. 3. Submitted a wish to the Portage developers. Actual Results: The proper KDE rev SHOULD have been checked out of the KDE repository, but this did not happen. Instead I had to open Konqueror and fill out a wish for the Portage developers to implement. Expected Results: The proper SVN revision should have been checked out with no changes on the part of the ebuild developers. Reproduceability? Doesn't happen in the future. =) For GIT/SVN layman and possibly even in-tree ebuilds, ~/ # REV="r38574" emerge package-category/package-name-9999 should check out the specified revision of said software. This helps for a) ebuild authors of some large projects that release many ebuilds just to stay caught up to a single release like kde4, or custom kernel patchset developers who no longer have to release a new ebuild or tarball for each release, instead simply placing a revision tag in the forums for others to use. A svn checkin and forum post is a lot cleaner / easier than releasing tarballs and ebuilds and might encourage developers to stick with the project. b) developers who want to be able to easily update a single point of functionality in a project under constant change while still retaining the ability to keep a stable base for any dependent parts under flux. e.g. updated konqueror with stable kdelibs, both from SVN. c) users, who want the latest software without having to wait for said developers to do unnecessary development on ebuilds which could take days with the amount of ebuilds to release. It isn't hard to see a few SVN/GIT ebuilds make their way into the official tree either, with a REV shell variable things would be swell for bleeding-edge users and developers. The biggest thing for me personally that this would help with at the moment is the kde4 svn ebuilds, as this would replace the kdesvn-build script and allow incremental upgrades to kde to watch progress unfold.
This has nothing to do w/ portage, it's the eclasses and ebuilds that handle it.
(In reply to comment #1) > This has nothing to do w/ portage, it's the eclasses and ebuilds that handle > it. > Yes, the eclasses of an overlay (genkdesvn) that explicitly tells you NOT to file bugs at bugs.gentoo.org. Sorry for the noise kde-folks.
To make this more clear, it's perfectly doable without doing anything package-manager wise, and even without the ebuild (unless it overrides the variable) - simply by using ESVN_OPTIONS="-r ${REV}" or similar equivalent for git/cvs/whatnot eclasses. If some of them doesn't make is possible, then fix the eclass. :)
