Summary: | Doc addition: Moving Portage to its own partition | ||
---|---|---|---|
Product: | [OLD] Docs-developer | Reporter: | Peter Hyman <pete4abw> |
Component: | Portage Documentation | Assignee: | Docs Team <docs-team> |
Status: | RESOLVED WONTFIX | ||
Severity: | enhancement | CC: | dev-portage |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Peter Hyman
2005-12-28 08:36:37 UTC
Portage team doesn't manage the handbook, reassigning to docs and cc'ing dev-portage. I'd also note Peter, that the cache update problem (50-51) is fixed in 2.1_preX. Hopefully with the new code this problem will not crop up again. However the idea of either moving the default /usr/portage to /var or /srv ( which is actually covered by another bug ) is a decent one, as well as putting portage on it's own partition ( especially if you have the cpu cycles to squashfs it ;) ). (In reply to comment #1) > > I'd also note Peter, that the cache update problem (50-51) is fixed in > 2.1_preX. I am very bad at searching bugzilla. Ask Jakub. I did not see this! > Hopefully with the new code this problem will not crop up again. However the > idea of either moving the default /usr/portage to /var or /srv ( which is > actually covered by another bug ) Oops, my bugzilla skills are exposed again... > is a decent one, as well as putting portage > on it's own partition ( especially if you have the cpu cycles to squashfs it ;) Actually, regardless, I agree that portage belongs elsewhere. As for squashfs, isn't that RO? How would that help? Well, I guess I was too impatient to wait for a portage update. It seems this issue has come and gone a couple of times. Separating portage into a unique partition will protect against future portage "enhancements". :) IMO, moving Portage to its own partition is beyond the scope of our handbook. |