Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] RFC: eutils.eclass: More reliable return status for e*_clean.
Date: Fri, 16 Feb 2018 14:53:01
Message-Id: 1518792770.22651.0.camel@gentoo.org
In Reply to: Re: [gentoo-dev] RFC: eutils.eclass: More reliable return status for e*_clean. by Michael Orlitzky
1 W dniu pią, 16.02.2018 o godzinie 08∶06 -0500, użytkownik Michael
2 Orlitzky napisał:
3 > On 02/16/2018 03:46 AM, Ulrich Mueller wrote:
4 > >
5 > > Should we take this as an opportunity to split off these three
6 > > functions into their own eclass, e.g. vcs-clean.eclass?
7 >
8 > I think this is a good direction to go in. Changing a popular eclass is
9 > always scary, and the more unrelated stuff it contains, the harder it
10 > gets. It's not easy to tell which ebuilds use the part of the eclass
11 > that you're touching, so you wind up testing (or at least worrying
12 > about) them all. There's the metadata regen, too.
13 >
14 > To make maintenance easier, I would go one step further and say that
15 > unless two functions need the same variables or call one another, they
16 > belong in separate eclasses. Since ecvs_clean, esvn_clean, and
17 > egit_clean are completely independent of one another, they could go in
18 > separate eclasses -- it's not like you'll need more than one of them in
19 > your ebuild. Then in the future if we need to change egit_clean, we will
20 > know precisely which ebuilds are affected.
21 >
22
23 When you reach the point of having one eclass per one-command function,
24 you should have already figured out it's easier to inline the command
25 in ebuilds.
26
27 --
28 Best regards,
29 Michał Górny