1 |
On Thu, 02 Jun 2005 19:36:59 +0200 |
2 |
"Dominik Bathon" <dbatml@×××.de> wrote: |
3 |
|
4 |
> I just had an idea: |
5 |
> |
6 |
> Portage could provide a new tool/function that would just take a |
7 |
> category-package-version string and a directory and would then |
8 |
> install the files in the given directory to ${ROOT}, like it would |
9 |
> normally install the files in ${PORTAGE_TMPDIR}/portage/${PF}/image. |
10 |
> |
11 |
> So the user could do a custom build but then let portage install and |
12 |
> manage the application. |
13 |
> |
14 |
> For example: |
15 |
> |
16 |
> cd foo |
17 |
> ./configure |
18 |
> make |
19 |
> mkdir image |
20 |
> make DESTDIR="image" install |
21 |
> new_tool bar/foo-1.0 image |
22 |
> |
23 |
> new_tool would then install the files in image to ${ROOT}, would add |
24 |
> those files to /var/db/pkg/bar/foo-1.0/CONTENTS, would fill the other |
25 |
> necessary files in /var/db/pkg/bar/foo-1.0/ with reasonable values |
26 |
> and maybe add bar/foo to world, so that it wouldn't be unmerged by |
27 |
> emerge depclean. |
28 |
> |
29 |
> This way the user could "inject" custom builds of packages into the |
30 |
> portage database. Portage could handle those packages as if they |
31 |
> were installed regularly. The user could even use this for |
32 |
> applications that are not in the portage tree, without having to |
33 |
> write an ebuild and putting it into his overlay. |
34 |
> |
35 |
> What do you think about that? |
36 |
|
37 |
Why don't you just write an ebuild in your PORTDIR_OVERLAY instead? |
38 |
Strikes me as the easier solution ... |
39 |
|
40 |
Marius |
41 |
|
42 |
-- |
43 |
Public Key at http://www.genone.de/info/gpg-key.pub |
44 |
|
45 |
In the beginning, there was nothing. And God said, 'Let there be |
46 |
Light.' And there was still nothing, but you could see a bit better. |