Re: [gentoo-dev] New eclass: autotools-multilib-minimal

[Michał Górny]

On Sun, 24 Feb 2013 05:22:43 +0100
hasufell <hasufell@g.o> wrote:

> Before people start asking I should explain why I started this:
> https://bugs.gentoo.org/show_bug.cgi?id=458638
>
> I think having such an eclass has several advantages over
> autootools-multilib.eclass (which depends on autotools-utils.eclass) as
> it is now:

You wanted the other points, so here you go.

> a) Less eclass dependencies. One could argue: the more eclasses my
> ebuild uses the more prone to error and exposed to changes it is.

That's as good as bundling libraries. Really.

> b) easier conversion in some cases: often times a simple rename
> src_compile -> multilib_src_compile will do

Easy != good. The eclass switch is a good point to fix bugs which
should have been fixed long ago. By making it unnecessary, you just
keep those bugs live and hidden.

> c) it allows more custom definition of phase functions

More custom than what?

> d) the previous point will also allow to convert go-mono.eclass packages
> without introducing yet another eclass for that

So you're introducing a hacky eclass just because you're too lazy to
convert go-mono packages properly and too impatient to let others do
the work properly for you?

> e) autotools-utils.eclass does a bit more than just calling default
> phase functions; the developer has little choice on this matter unless
> he wants to rewrite his ebuild based on multilib-build.eclass which will
> create a lot of code duplication in ebuilds, hence this proposition

And as I already told you, this argument just proves that you don't
know the eclass in question and just throwing random accusations.

> I don't have a problem with the present eclasses, but I find this a
> logical enhancement.

If that's logical, then please provide a graph showing where it
logically fits. Because so far, it's either hate-built redundant eclass
or quick draft eclass written for a single package.

-- 
Best regards,
Michał Górny