public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Tim Harder <radhermit@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] EGO_SUM (was: [gentoo-project] Gentoo Council Election 202306 ... Nominations Open in Just Over 24 Hours.)
Date: Fri, 30 Jun 2023 03:38:11 -0600	[thread overview]
Message-ID: <ZJ6ig2uJfF4cjUVH@fir> (raw)
In-Reply-To: <87jzvl2vzh.fsf@gentoo.org>

On 2023-06-30 Fri 02:22, Sam James wrote:
> My position on this has been consistent: a check is needed to statically
> determine when the environment size is too big. Copying the Portage
> check into pkgcheck (in terms of the metrics) would satisfy this.
> 
> That is, regardless of raw size, I'm asking for a calculation based on
> the contents of EGO_SUM where, if exceeded, the package will not be
> installable on some systems. You didn't have an issue implementing this
> for Portage and I've mentioned this a bunch of times since, so I thought
> it was clear what I was hoping to see.
> 
> I would also like (which is not what I was referring to here) some
> limit on the size, given that we already have a limit on the size of
> ${FILESDIR}, but this is less of a concern for me given it's bounded
> by the aforementioned environment size check.

Why do we have to keep exporting the related variables that generally
cause these size issues to the environment? I've asked as much on IRC
multiple times (nearly every time this discussion has been brought up)
and the answers I've gotten are some variation on "it's always been that
way" or "not exporting them would break using commands as external
programs" (e.g. calling via xargs).

The first response isn't a great argument and the second response, while
more valid, also feels less important than having a more minimalistic,
exported environment that causes less issues like this one and others
such as potentially affecting a package's build system in an unexpected
fashion. See bug #721088 for the related discussion on environment
variable exports.

From my stance, the spec should state that the only variables to be
exported are ones already "semi-standard" and used externally of package
manager internals in the expected fashion, which probably only includes
HOME, TMPDIR, and maybe ROOT. This would of course currently break
packages that use `xargs` while calling internal commands depending on
some of those exported variables, but from a cursory glance at the
gentoo repo, there aren't many ebuilds using that functionality and in
general those that are could be written in an easier to understand
fashion without using xargs. It should also be possible to proxy the
required variables to those commands in various fashions without using
the environment if using commands externally is extremely important to
the few ebuild maintainers who make use of that functionality.

In short, adding checks to portage and pkgcheck feels like a ill-suited
workaround that foists hacking around the error onto users or developers
due to a poor decision made decades ago on environment handling.

Tim


  reply	other threads:[~2023-06-30  9:38 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <2ZKWN4KF.MKEFFMWE.LGPKYP47@RTL7EJXF.RN4PF6UF.MDFBGF3C>
     [not found] ` <be450641-94ff-a0d9-51da-3a7a3abcc6c7@gentoo.org>
     [not found]   ` <b7309a3f-2980-b390-a16a-0518cce1da75@gentoo.org>
     [not found]     ` <87y1k33aoy.fsf@gentoo.org>
2023-06-30  8:15       ` [gentoo-dev] EGO_SUM (was: [gentoo-project] Gentoo Council Election 202306 ... Nominations Open in Just Over 24 Hours.) Florian Schmaus
2023-06-30  8:22         ` Sam James
2023-06-30  9:38           ` Tim Harder [this message]
2023-06-30 11:33             ` Eray Aslan
2023-07-03 10:17               ` Florian Schmaus
2023-07-04  7:13                 ` Tim Harder
2023-07-04 10:44                   ` Gerion Entrup
2023-07-04 21:56                     ` Robin H. Johnson
2023-07-04 23:09                       ` Oskari Pirhonen
2023-07-05 18:40                         ` Gerion Entrup
2023-07-05 19:32                           ` Rich Freeman
2023-07-06  2:48                           ` Oskari Pirhonen
2023-07-06  6:09                   ` Zoltan Puskas
2023-07-06 19:46                     ` [gentoo-dev] EGO_SUM (was: [gentoo-project] Gentoo Council Election 202306 ... Nominations Open Hank Leininger
2023-07-08 20:49                     ` [gentoo-dev] EGO_SUM (was: [gentoo-project] Gentoo Council Election 202306 ... Nominations Open in Just Over 24 Hours.) Sam James
2023-07-03 10:17           ` Florian Schmaus
2023-07-03 11:12             ` [gentoo-dev] EGO_SUM Ulrich Mueller
2023-07-08 21:21             ` [gentoo-dev] EGO_SUM (was: [gentoo-project] Gentoo Council Election 202306 ... Nominations Open in Just Over 24 Hours.) Sam James
     [not found]     ` <cdf5ddb7-8f65-74cf-5594-3e3eec86c915@gentoo.org>
     [not found]       ` <1913d3c2-5f54-acea-0ed3-930371ea1884@gentoo.org>
     [not found]         ` <CAAr7Pr9+zq2NV=7zhj5e+4LWOmNavCrfMstNTqkthk5uxQVNtg@mail.gmail.com>
2023-07-14  7:14           ` [gentoo-dev] Re: Flow's Manifesto and questions for nominees (was: " Florian Schmaus
2023-07-14  7:33             ` Sam James
2023-07-14  8:19               ` Sam James
2023-07-14  9:07               ` Florian Schmaus
2023-07-14  8:39             ` [gentoo-dev] Re: Flow's Manifesto and questions for nominees Ulrich Mueller

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=ZJ6ig2uJfF4cjUVH@fir \
    --to=radhermit@gentoo.org \
    --cc=gentoo-dev@lists.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