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

[hasufell <hasufell@gentoo.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/24/2013 03:57 PM, Michał Górny wrote:
> On Sun, 24 Feb 2013 05:22:43 +0100 hasufell <hasufell@gentoo.org>
> 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.

That analogy is flawed. It's about ebuild design and the fact that I
don't just convert my ebuild to _multilib_, but also to
_autotools-utils_, so I have to keep an eye on another provider.

> 
>> 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?

Than autotools-multilib.eclass.

> 
>> 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?

Please point out where the eclass is hacky. I haven't heard a
technical argument against it despite that you think
autotools-multilib.eclass is better.
That might be true, but then I don't understand why people refuse to
use it which is the only reason I am proposing this.

Also, I am not too lazy to convert go-mono packages. I have already
written the go-mono-multilib.eclass and it looks almost the same as
autotools-multilib-minimal.eclass, so I am wondering why I want
code-duplication in eclasses.

> 
>> 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.
> 

No, I was just rephrasing other peoples concerns.

>> 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.
> 

I don't understand you.
It works on more than one package.


Anyway... as I said, I don't care how this problem is solved. I only
care about the availability of 32bit libs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRKi3GAAoJEFpvPKfnPDWzkW4H/3uaQ++8Rky1GKi+Tvffz45i
x+yNpPtje/gWFKjXVeWxQZfNV/tLsq1TZM0ruzixB6lO1vFD6Ql+8ZiuTrHHRvuV
at3+iT2AycSTeNs0qRUHjICOn5V6fMNQyIxJsrFS+HNEEbYfE36+S91YvN9WwHr6
Q2PDBp+3jueJXNVeZh+zdSQL4eo2fEuJ39/pa42SPbeRGGm6aw1SnhD9RYBcRZuf
GyuTOk7R+vwp55i4d7xXyb8eEDVh7uSqikb7OniNA15a7wrmpSLsfwonhZS/a3Qq
R/pQDXGm+aDDk7ZwXGCWRvGd7ARLqED5A+5yKcfyQeZ99RP6KHW8+xEwkr8M54I=
=3uKD
-----END PGP SIGNATURE-----