Summary: | Patch Overlay similar to portage tree overlay | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Matthias Hoermann <taladar> |
Component: | Eclasses | Assignee: | Portage team <dev-portage> |
Status: | VERIFIED LATER | ||
Severity: | enhancement | CC: | radek |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Matthias Hoermann
2005-06-24 09:35:21 UTC
I'm second that. Having to dig into ebuild (and doing all the overlay stuff) is a bit of overkill for simple things... The complexity of Portage isn't low now and if you're able to apply a patch and deal with the "consequences", you should be able to maintain your own ebuild in your overlay. People are do not even rename the eclasses they copy to their overlay and push their local problems to bugs.g.o because they forget about it or are not able to track it down. With arbitrary patches this may become even worse. I oppose such a feature. Most really useful features make it easier to break things but that doesn't mean they should be thrown away without further thought. Perhaps applied patches could be listed in emerge info (or a similar command where the output can then be posted to the forum when someone has a problem), as should ebuilds in the portage overlay with some kind of checksum. Of course it should filter out the ones simply sitting in the overlay so only installed ones are listed. Putting a hold on feature requests for portage as they are drowning out the bugs. Most of these features should be available in the next major version of portage. But for the time being, they are just drowning out the major bugs and delaying the next version's progress. Any bugs that contain patches and any bugs for etc-update or dispatch-conf can be reopened. Sorry, I'm just not good enough with bugzilla. ;) Doable with src_unpack hooks in bashrc now. |