| 1 |
On 12/20/06, Benno Schulenberg <benno.schulenberg@×××××.com> wrote: |
| 2 |
> Mark Knecht wrote: |
| 3 |
> > At that point it's gone. I cannot put into an overlay |
| 4 |
> > what I don't have. Probably most frustrating has been that I |
| 5 |
> > don't know it will be removed until it's been removed. |
| 6 |
> |
| 7 |
> You could, as soon as you have a system in a working state, tar up |
| 8 |
> the entire /usr/portage tree, and then, when you find an upgrade |
| 9 |
> has broken an essential package, untar the ball over your new tree, |
| 10 |
> and re-emerge the old version of the package. Once a month or so, |
| 11 |
> when you find that also the newest tree gives you a working system, |
| 12 |
> you would tar up that /usr/portage instead and remove the old one. |
| 13 |
> This is the dead simple, brute force way, no overlay required. :) |
| 14 |
> |
| 15 |
> Benno |
| 16 |
> |
| 17 |
|
| 18 |
Yes, I think this is a simple answer. A bit difficult for 5-7 machines |
| 19 |
if I do it separately for each, but not too bad. |
| 20 |
|
| 21 |
If I wanted to take the plunge I should probably learn to run my own |
| 22 |
portage server where I suppose I could learn to keep things like this |
| 23 |
even if the main server wants to get rid of things. |
| 24 |
|
| 25 |
The thing is that I don't want to start ignoring valid reasons to get |
| 26 |
rid of packages, like security problems or broken code that's fixed in |
| 27 |
new revs. |
| 28 |
|
| 29 |
Anyway, I appreciate all the ideas and everyone's POV. I'm just |
| 30 |
speaking from what I've seen and experienced. |
| 31 |
|
| 32 |
Cheers and out for now, |
| 33 |
Mark |
| 34 |
-- |
| 35 |
gentoo-user@g.o mailing list |
Archives