| 1 |
On 02/16/2018 03:46 AM, Ulrich Mueller wrote: |
| 2 |
> |
| 3 |
> Should we take this as an opportunity to split off these three |
| 4 |
> functions into their own eclass, e.g. vcs-clean.eclass? |
| 5 |
|
| 6 |
I think this is a good direction to go in. Changing a popular eclass is |
| 7 |
always scary, and the more unrelated stuff it contains, the harder it |
| 8 |
gets. It's not easy to tell which ebuilds use the part of the eclass |
| 9 |
that you're touching, so you wind up testing (or at least worrying |
| 10 |
about) them all. There's the metadata regen, too. |
| 11 |
|
| 12 |
To make maintenance easier, I would go one step further and say that |
| 13 |
unless two functions need the same variables or call one another, they |
| 14 |
belong in separate eclasses. Since ecvs_clean, esvn_clean, and |
| 15 |
egit_clean are completely independent of one another, they could go in |
| 16 |
separate eclasses -- it's not like you'll need more than one of them in |
| 17 |
your ebuild. Then in the future if we need to change egit_clean, we will |
| 18 |
know precisely which ebuilds are affected. |
Archives