| 1 |
Mark Knecht posted on Thu, 27 Aug 2009 09:25:01 -0700 as excerpted: |
| 2 |
|
| 3 |
> If it see this it would automatically moved a copy of ebuilds and |
| 4 |
> distfiles into some sort of a local 'in-use' overlay so they'd still be |
| 5 |
> available to me on this machine. With something like that at least then |
| 6 |
> nothing would be lost. Maybe then there's a little app to allow me to |
| 7 |
> remove it from the overlay when I'm done wit it, or I'd do it by hand. |
| 8 |
> |
| 9 |
> What I dislike about the current system is some person out there in the |
| 10 |
> ether deciding what's right for my hardware with the main criteria being |
| 11 |
> what's easy for him. Yes, I can, by hand and with time and training, |
| 12 |
> eventually find and replace things I need, but I have never thought the |
| 13 |
> way it is working now was the right way. |
| 14 |
|
| 15 |
You're aware that you have a copy of the existing installed ebuild in the |
| 16 |
portage installed-packages database (typically /var/db/portage), right? |
| 17 |
That also contains a copy of the environment used to install the package |
| 18 |
as well, so all the eclasses as they were at installation, etc, tho it'd |
| 19 |
be a bit of work to reconstruct that. And I'm not sure about the patches |
| 20 |
if any were applied. But the ebuild, that's easy, and that's the most |
| 21 |
frequently needed bit. |
| 22 |
|
| 23 |
For those with FEATURES=buildpkg, the ebuild is also glued to the end of |
| 24 |
the tarball containing the built binaries. I happened to discover that |
| 25 |
before I did the /var/db/portage database, and used an editor to grab the |
| 26 |
ebuild out of the binpkg a couple of times. |
| 27 |
|
| 28 |
-- |
| 29 |
Duncan - List replies preferred. No HTML msgs. |
| 30 |
"Every nonfree program has a lord, a master -- |
| 31 |
and if you use the program, he is your master." Richard Stallman |
Archives