| 1 |
Hi, |
| 2 |
|
| 3 |
>> now why cant we apply this technique to track whether the package is |
| 4 |
>> already installed in our system not through portage and inject into |
| 5 |
>> the database??........ |
| 6 |
> |
| 7 |
> Where to get this list of files from??........ |
| 8 |
|
| 9 |
I just had an idea: |
| 10 |
|
| 11 |
Portage could provide a new tool/function that would just take a |
| 12 |
category-package-version string and a directory and would then install the |
| 13 |
files in the given directory to ${ROOT}, like it would normally install |
| 14 |
the files in ${PORTAGE_TMPDIR}/portage/${PF}/image. |
| 15 |
|
| 16 |
So the user could do a custom build but then let portage install and |
| 17 |
manage the application. |
| 18 |
|
| 19 |
For example: |
| 20 |
|
| 21 |
cd foo |
| 22 |
./configure |
| 23 |
make |
| 24 |
mkdir image |
| 25 |
make DESTDIR="image" install |
| 26 |
new_tool bar/foo-1.0 image |
| 27 |
|
| 28 |
new_tool would then install the files in image to ${ROOT}, would add those |
| 29 |
files to /var/db/pkg/bar/foo-1.0/CONTENTS, would fill the other necessary |
| 30 |
files in /var/db/pkg/bar/foo-1.0/ with reasonable values and maybe add |
| 31 |
bar/foo to world, so that it wouldn't be unmerged by emerge depclean. |
| 32 |
|
| 33 |
This way the user could "inject" custom builds of packages into the |
| 34 |
portage database. Portage could handle those packages as if they were |
| 35 |
installed regularly. The user could even use this for applications that |
| 36 |
are not in the portage tree, without having to write an ebuild and putting |
| 37 |
it into his overlay. |
| 38 |
|
| 39 |
What do you think about that? |
| 40 |
|
| 41 |
Dominik |
| 42 |
-- |
| 43 |
gentoo-portage-dev@g.o mailing list |
Archives