| 1 |
В Вск, 30/11/2008 в 16:10 +0100, Santiago M. Mola пишет: |
| 2 |
> per-package eclasses [1]. |
| 3 |
> That way, it would be easy to avoid duplication of not only HOMEPAGE but |
| 4 |
> also SRC_URI, LICENSE, or any other part of an ebuild. |
| 5 |
|
| 6 |
Having per-package eclasses (PPE) just to set common HOMEPAGE is |
| 7 |
definitely overkill. What other reasons for PPE to exist? |
| 8 |
|
| 9 |
If you want to separate common code, then PPE is very dangerous. |
| 10 |
|
| 11 |
Take for example ebuilds which share same src_*() function which you had |
| 12 |
to modify a bit with version bump. To be absolutely sure that you have |
| 13 |
not broke anything you'll have to check all versions of the package or |
| 14 |
there are chances that you broke stable tree and have not noticed that. |
| 15 |
Of course the same stands for eclasses. The difference between PPE and |
| 16 |
global eclasses is that 1. PPE covers less packages and it'll take |
| 17 |
longer to notice that error 2. per-package things are changing more |
| 18 |
rapidly and thus more changes to PPE will be required. All this means |
| 19 |
that we'll have more breakages. So what are the benefits to overbalance |
| 20 |
this minuses? |
| 21 |
|
| 22 |
-- |
| 23 |
Peter. |
Archives