From: Pacho Ramos <pacho@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Cc: mgorny@gentoo.org
Subject: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/freetype: freetype-2.4.11-r1.ebuild ChangeLog
Date: Wed, 27 Feb 2013 21:20:46 +0100 [thread overview]
Message-ID: <1361996446.1929.7.camel@belkin4> (raw)
In-Reply-To: <512E3E06.8010205@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 1917 bytes --]
El mié, 27-02-2013 a las 18:10 +0100, hasufell escribió:
> I don't want to start another useless rant here, because I perfectly
> understand the issue with ABI specific headers.
>
> The problem is:
> a) if you break a provider on purpose, then you should feel
> somehow responsible for the consumers and not just dump testing and
> fixing on your fellow devs
> b) just test such things in an overlay first and see it explode, then
> think about it again and ask on dev-ML if other people find it even
> WORTH the hassle
>
>
> The other thing is:
> We still have the conflict with eclass-solution vs PM-solution
> (multilib-portage) and I propose not to convert ANYTHING else until that
> conflict is solved, even if it means a council vote (that's what I
> actually think makes sense here).
> I understand both sides and somehow find it appealing to have a quicker
> solution, but since this could damage years of work on a portage fork I
> think we should slow down here.
>
>
Personally I don't think mgorny "broke a provider on purpose", he should
have released it hardmasked, but thinking he wanted to break testing on
purpose looks excessive to me. Also, most of that committed stuff was
tested for some time in x11 overlay, no? (not sure if probably freetype
was missed by some error, but clearly the transition to the eclasses
providing native multilib were tested "on purpose" in that overlay
before moving to the tree).
About PM-solution... I can't remember how many years we are waiting it
for being approved, and neither remember what was blocking it for
inclusion in eapi5 (as that threads usually end up being fairly long and
ending with blockers like PMS documentation changes and so :( )
I also remember this "conflict" between portage-multilib and eclasses
ways were discussed some weeks ago here (I thought specially between
mgorny and... aballier?)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2013-02-27 20:20 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20130225222029.D84D12171D@flycatcher.gentoo.org>
2013-02-27 17:10 ` [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/freetype: freetype-2.4.11-r1.ebuild ChangeLog hasufell
2013-02-27 17:58 ` Alexis Ballier
2013-02-27 18:14 ` hasufell
2013-02-27 18:27 ` Alexis Ballier
2013-02-27 19:05 ` hasufell
2013-02-27 19:09 ` Ciaran McCreesh
2013-03-02 11:08 ` Alexis Ballier
2013-03-02 15:01 ` hasufell
2013-02-27 20:25 ` Pacho Ramos
2013-02-27 21:12 ` Thomas Sachau
2013-03-02 10:55 ` Alexis Ballier
2013-02-27 20:30 ` Pacho Ramos
2013-02-27 21:08 ` Thomas Sachau
2013-02-27 21:18 ` Michał Górny
2013-03-02 10:53 ` Alexis Ballier
2013-02-27 18:15 ` Diego Elio Pettenò
2013-02-27 20:20 ` Pacho Ramos [this message]
2013-02-27 20:23 ` Ciaran McCreesh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1361996446.1929.7.camel@belkin4 \
--to=pacho@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
--cc=mgorny@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox