Bug 82356
| Summary: | gmake -> gmake-devel repocopy request | ||
|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Sergey Matveychuk <sem> |
| Component: | Individual Port(s) | Assignee: | Ade Lovett <ade> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | Latest | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Sergey Matveychuk
2005-06-17 13:00:36 UTC
State Changed From-To: open->repocopy devel/gmake -> devel/gmake-devel repocopy request Responsible Changed From-To: freebsd-ports-bugs->portmgr devel/gmake -> devel/gmake-devel repocopy request State Changed From-To: repocopy->feedback This port will not be copied until the current maintainer of gmake signs off on it. Responsible Changed From-To: portmgr->sem This port will not be copied until the current maintainer of gmake signs off on it. State Changed From-To: feedback->closed Sorry, such a repocopy will lead to considerable confusion over which gmake to use. No other infrastructure changes would happen, so this is likely to turn into an enormous problem, for minimal (if any) gain. Submitter can certainly offer up the patchset for others to try, but another port is simply not the right way to do things here - the current fun and games with various bison ports should be a pretty good indication of how such well-intentioned ideas can lead to major problems further down the road. As and when the GNU make folks release a new version of gmake, it will certainly be adopted, after testing, and it is this approach that should be considered here. Responsible Changed From-To: sem->ade gmake MAINTAINER hat on. |