| 1 |
On Fri, 20 Jul 2007 11:52:02 +0200 |
| 2 |
Michael Hanselmann <hansmi@g.o> wrote: |
| 3 |
|
| 4 |
> Hello Benedikt |
| 5 |
> |
| 6 |
> On Fri, Jul 13, 2007 at 01:37:11PM +0200, Benedikt Boehm wrote: |
| 7 |
> > It is basically netqmail split into much smaller chunks so they can |
| 8 |
> > be reused by other qmail variants as well. |
| 9 |
> |
| 10 |
> Okay, I looked through it and found some things which need |
| 11 |
> reconsideration. I agree that user creation and such things can be |
| 12 |
> easily done in an eclass. However, functions like qmail_src_unpack |
| 13 |
> should be done in the ebuild. Putting them in an eclass and just doing |
| 14 |
> "if (a) { … } else if (b) { … }" makes it harder to understand and |
| 15 |
> unneccessarily complicated. |
| 16 |
|
| 17 |
I absolutely agree here, it is just too ugly. |
| 18 |
|
| 19 |
> qmail_base_install should be split in |
| 20 |
> smaller functions, maybe with callbacks (if possible in bash). |
| 21 |
|
| 22 |
There is now qmail_mini_install (called by every qmail ebuild) and |
| 23 |
qmail_{full,man,sendmail}_install for the rest of a full blown install. |
| 24 |
|
| 25 |
I'm not sure what you mean with "callbacks" here, maybe you can |
| 26 |
elaborate? |
| 27 |
|
| 28 |
> In the |
| 29 |
> end the ebuild shouldn't contain any package-specific code. Can you |
| 30 |
> look into it again? |
| 31 |
|
| 32 |
The qmail_*_install changes are already in my overlay, i will look into |
| 33 |
removing the unpack stuff from the eclass together with some |
| 34 |
DEPEND/IUSE cleanups to get rid of qmail_mini() tomorrow. |
| 35 |
|
| 36 |
HTH, |
| 37 |
Bene |
| 38 |
-- |
| 39 |
gentoo-dev@g.o mailing list |
Archives