From: "Michał Górny" <mgorny@gentoo.org>
To: Kent Fredric <kentfredric@gmail.com>
Cc: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] rfc: calling all eclass phase functions by default
Date: Sun, 17 Aug 2014 09:03:44 +0200 [thread overview]
Message-ID: <20140817090344.7cb7010a@pomiot.lan> (raw)
In-Reply-To: <CAATnKFB4E3UrQgeRvi5h0N0tXkhUT8mR3Yk56t2hiy9afojqCQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 998 bytes --]
Dnia 2014-08-17, o godz. 10:32:14
Kent Fredric <kentfredric@gmail.com> napisał(a):
> So if you could sculpt it to be broader by default and have less scope for
> developer error, that'd be an improvement.
>
> --- code start --
> ECLASS_EXCLUDE="foo_src_unpack bar_src_unpack"
> inherit foo bar baz
>
>
> --- code end ---
>
> here, src_unpack would be baz_src_unpack *regardless* of composition order
> because "foo" and "bar" were barred from being used, and baz took
> precedence as a result.
Wow, so you suggest replacing a solution where you have to re-declare
all the phases with one in which you have to opt-out of all phases of
all eclasses...
This thread spreads more great ideas every minute. Soon enough, we will
ban eclasses and require every ebuild to write everything inline just
to be sure. Preferably using kernel calls from assembly to avoid as much
middleware as possible, and make ebuilds as verbose as possible.
--
Best regards,
Michał Górny
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 949 bytes --]
next prev parent reply other threads:[~2014-08-17 7:04 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-16 21:54 [gentoo-dev] rfc: calling all eclass phase functions by default William Hubbs
2014-08-16 22:32 ` Kent Fredric
2014-08-16 23:01 ` William Hubbs
2014-08-17 3:11 ` [gentoo-dev] " Duncan
2014-08-17 7:03 ` Michał Górny [this message]
2014-08-17 8:49 ` [gentoo-dev] " Kent Fredric
2014-08-17 7:06 ` "Paweł Hajdan, Jr."
2014-08-17 7:18 ` Michał Górny
2014-08-17 7:23 ` "Paweł Hajdan, Jr."
2014-08-16 22:54 ` Michał Górny
2014-08-16 23:30 ` William Hubbs
2014-08-17 6:54 ` Ulrich Mueller
2014-08-17 12:24 ` Rich Freeman
2014-08-18 8:54 ` Sergey Popov
2014-08-18 10:44 ` Rich Freeman
2014-08-18 12:21 ` Sergey Popov
2014-08-18 13:27 ` Rich Freeman
2014-08-18 12:04 ` hasufell
2014-08-18 12:19 ` Sergey Popov
2014-08-18 12:30 ` hasufell
2014-08-18 12:41 ` hasufell
2014-08-18 12:52 ` Michał Górny
2014-08-18 12:56 ` hasufell
2014-08-18 13:22 ` Chris Reffett
2014-08-18 13:27 ` hasufell
2014-08-18 15:11 ` Michał Górny
2014-08-18 19:37 ` Chris Reffett
2014-08-18 20:08 ` Michał Górny
2014-08-18 20:23 ` hasufell
2014-08-19 7:02 ` Sergey Popov
2014-08-18 14:13 ` Rich Freeman
2014-08-19 6:58 ` Sergey Popov
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=20140817090344.7cb7010a@pomiot.lan \
--to=mgorny@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
--cc=kentfredric@gmail.com \
/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