| 1 |
On Thu, Aug 09, 2001 at 09:53:02PM +0200, Hendrik Visage wrote: |
| 2 |
> Hi there, |
| 3 |
> |
| 4 |
> One of my personal main "gripes" about the portage/ports/.srpm etc. |
| 5 |
> setups, are that I can't "tune" the installation in a managed fashion, |
| 6 |
> |
| 7 |
> An example is flwm (Nothing against tadpol, thanx for the -r1 :) |
| 8 |
> that have some interesting configuration changes that can only be made in |
| 9 |
> the config.h file before compilation. |
| 10 |
> |
| 11 |
> Now my wishlist for ebuilds etc. |
| 12 |
> I'd like to have a interactive setup or step by step changes, |
| 13 |
> ie. |
| 14 |
> issue the standard installation (Let's see if it install by default) |
| 15 |
> Then I'd like to ask it to extract the package, but to let me add some extra |
| 16 |
> ./configure options (Enable this or disable that), eg. I'd like to have a text |
| 17 |
> console only xemacs, or I'd like to have xaw instead of lucid menus etc. etc. |
| 18 |
> Then I'd like it to do the configure, and after that I'd like the possibility |
| 19 |
> to vi some config.c for some changes in the system in the way *I* want it. |
| 20 |
> Then let it do the compile & install. |
| 21 |
|
| 22 |
One of the decisions to make is whether we should expose the underlying |
| 23 |
configuration mechanism for the package, say by having a process much like |
| 24 |
Pete described, where the user does: |
| 25 |
1) ebuild unpack |
| 26 |
2) edits a pre-generated <package-install-prefix>/gentoo-configure script |
| 27 |
3) ebuild merge |
| 28 |
|
| 29 |
In step 3, the portage system will use the modified gentoo-configure |
| 30 |
script to configure the package, before running make and install. |
| 31 |
|
| 32 |
This can be handled by portage, more or less by dumping |
| 33 |
src_compile() to the gentoo-configure file. |
| 34 |
|
| 35 |
|
| 36 |
The other approach, which would make creating ebuilds considerably more |
| 37 |
difficult, was to have each ebuild read a parameter list from command |
| 38 |
line, then apply these to the underlying configuration mechanism for the |
| 39 |
relevant package. |
| 40 |
|
| 41 |
This would mean that the user doing installation wouldn't have to know the |
| 42 |
intricacies of the underlying package (not all packages use automake), but |
| 43 |
would only specify a parameter to ebuild, e.g: |
| 44 |
ebuild clanlib-0.5.0.ebuild --with-3d |
| 45 |
|
| 46 |
Then it was up to the ebuild code to map the "--with-3d" parameter to |
| 47 |
whatever was appropriate in clanlib (such as "--with-opengl"). Normally, |
| 48 |
there would be a direct mapping. |
| 49 |
|
| 50 |
However, this puts the burden on the ebuild developer to export many (if |
| 51 |
not all) of the compile-time switches, and perhaps even write some kind of |
| 52 |
consistency-checker for some of the parameters, if the underlying |
| 53 |
configuration systems doesn't handle that (say, the user specified |
| 54 |
--without-x --with-gtk). |
| 55 |
|
| 56 |
|
| 57 |
The current philosophy of portage (and consequently ebuild) has been KISS. |
| 58 |
The Gentoo developers have opted for the easiest route, |
| 59 |
implementation-wise. |
| 60 |
|
| 61 |
> Or am I missing a documentation page?? |
| 62 |
|
| 63 |
No, we do not have direct support for this. |
| 64 |
|
| 65 |
|
| 66 |
|
| 67 |
This is definitely a topic that is relevant to the "Improving |
| 68 |
Portage"-project I've suggested elsewhere. |
| 69 |
|
| 70 |
Regards, |
| 71 |
|
| 72 |
Karl T |
Archives