From: Sam James <sam@gentoo.org>
To: "Michał Górny" <mgorny@gentoo.org>
Cc: gentoo-dev@lists.gentoo.org, Eli Schwartz <eschwartz@gentoo.org>
Subject: Re: [gentoo-dev] [PATCH v2 1/2] sec-keys.eclass: new eclass
Date: Thu, 28 Nov 2024 17:22:28 +0000 [thread overview]
Message-ID: <87iks7b7e3.fsf@gentoo.org> (raw)
In-Reply-To: <bc36861e60147ba6d72ccac173309b7c4cb4dba2.camel@gentoo.org> ("Michał Górny"'s message of "Thu, 28 Nov 2024 18:06:17 +0100")
Michał Górny <mgorny@gentoo.org> writes:
> On Thu, 2024-11-28 at 16:56 +0000, Sam James wrote:
>> Eli Schwartz <eschwartz@gentoo.org> writes:
>>
>> > On 11/28/24 8:10 AM, Michał Górny wrote:
>> > > On Wed, 2024-11-27 at 23:32 -0500, Eli Schwartz wrote:
>> > >
>> > > That looks like something you could do in src_compile() already.
>> >
>> >
>> > Perhaps. But it felt like exporting keys is work that is conceptually
>> > part of installing, in much the way that running a meson project's
>> > `meson install` step does more than just copy files into ${D} -- it also
>> > processes those files in order to do things like patch the rpath.
>> >
>> > I guess I am not too attached to either approach.
>>
>> I think I very loosely prefer doing it in src_compile as it's
>> "compilation" of the resulting files and then src_install just moving
>> the bundle, but I hardly feel strongly about it at all and feel it's
>> personal preference. Not worth the electrons ;)
>
> My point was mostly that you wouldn't have to start with GNUPGHOME
> again. Also, tests might be able to reuse the result then. Also, tests
> wouldn't be able to mess up src_install() (think of test-fail-continue
> too).
Ah, test-fail-continue is a good point.
next prev parent reply other threads:[~2024-11-28 17:22 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-27 20:30 [gentoo-dev] [PATCH 1/2] sec-keys.eclass: new eclass Eli Schwartz
2024-11-27 20:30 ` [gentoo-dev] [PATCH 2/2] sec-keys/openpgp-keys-gnutls: update to use sec-keys.eclass Eli Schwartz
2024-11-27 21:12 ` [gentoo-dev] [PATCH 1/2] sec-keys.eclass: new eclass Michał Górny
2024-11-27 21:52 ` Sam James
2024-11-28 4:24 ` Eli Schwartz
2024-11-27 21:57 ` Sam James
2024-11-28 4:17 ` Eli Schwartz
2024-11-28 4:32 ` [gentoo-dev] [PATCH v2 0/2] sec-keys.eclass Eli Schwartz
2024-11-28 4:32 ` [gentoo-dev] [PATCH v2 1/2] sec-keys.eclass: new eclass Eli Schwartz
2024-11-28 13:10 ` Michał Górny
2024-11-28 15:36 ` Eli Schwartz
2024-11-28 16:42 ` Michał Górny
2024-11-28 16:56 ` Sam James
2024-11-28 17:06 ` Michał Górny
2024-11-28 17:22 ` Sam James [this message]
2024-11-29 18:31 ` Robin H. Johnson
2024-11-29 19:02 ` Eli Schwartz
2024-11-29 7:30 ` Florian Schmaus
2024-11-28 4:32 ` [gentoo-dev] [PATCH v2 2/2] sec-keys/openpgp-keys-gnutls: update to use sec-keys.eclass Eli Schwartz
2024-11-28 10:35 ` [gentoo-dev] [PATCH 1/2] sec-keys.eclass: new eclass Ulrich Müller
2024-11-28 15:36 ` Eli Schwartz
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=87iks7b7e3.fsf@gentoo.org \
--to=sam@gentoo.org \
--cc=eschwartz@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