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