| 1 |
> In theory, Portage could track them if ebuild could be modified to use |
| 2 |
> /usr/src/pkg when it existed instead of /var/tmp/portage/*/work and |
| 3 |
> the application was installed via 'ebuild pkg merge'. I'm not sure how |
| 4 |
> possible that would be for implementation, though. |
| 5 |
|
| 6 |
But then the question is: Why? We already have the source unpacked in |
| 7 |
/var/tmp/portage/*/work so why "move" it to /usr/src? There are already |
| 8 |
ways for people to do the configure- and make-steps them selves if they |
| 9 |
wish (through the ebuild-command as you yourself said). As I see it |
| 10 |
there would be no advantage reimplementing it the proposed way... |
| 11 |
As for the kernels to be auto-configured, why not do it the same way as |
| 12 |
some other packages do it: have an extra section in the ebuild that |
| 13 |
configures the kernel for you through genkernel... Several other |
| 14 |
packages already have this section (think it's called config) including |
| 15 |
postresql. This could be advertised in the same way as in the |
| 16 |
postresql-ebuild at the end of the emerge-command, and thus everybody |
| 17 |
has a choice in how they would like to configure and compile the kernel. |
| 18 |
|
| 19 |
Patrick Börjesson |
| 20 |
|
| 21 |
-- |
| 22 |
Public key id: 4C5AB0BF |
| 23 |
Public key available at search.keyserver.net[:11371] |
Archives