El dom, 24-02-2013 a las 15:57 +0100, Michał Górny escribió:
[...]
> > 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?

Would be nice to know what autotools-utils.eclass is doing differently
that is showing this problem with go-mono.eclass packages :/

Only one question, what is the reason for us having base.eclass and
autotools-utils.eclass? I still try to use plain ebuilds without
inheritting autotools-utils.eclass as I usually don't need it, probably
others do the same and refuse to have to inherit it only for multilib
support :/ How do you plan to solve this problem?

I would also like to hear why that people refuses to use
autotools-utils.eclass... because I don't have a strong opinion on this
topic 

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to