I am sorry but we cannot do much here. The requirements for memory is related to metadata size for particular repository. DNF (libsolv) downloads particular repository then it converts data to internal format (in RAM) and then it stores process data to disk and then it frees the memory. If repository if big it requires more RAM then for the small one.

How the problem can be resolved?
1. Use only small repositories - Distribution can resolve the issue
2. Make loading file list optional - we will resolve it in the next generation of software management tool - DNF5/LIBDNF5 - RFE for Fedora 38+
3. Change libsolv to use RAM more efficiently - nice dream because it handles a lot of data
4. Delivery less files, provides, and requires in RPMs > smaller repositories, faster resolve of dependencies, requires less RAM to process. Right now it is permanently growing
5. Use compression of metadata that requires less RAM to decompress - Distribution can resolve the issue

Is it an issue?
The minimal requirement for Fedora is 2 GB of RAM.

BetaBlocker -1 FinalBlocker -1

On the whole I'm:

BetaBlocker -1

as running dnf in 512M of RAM just doesn't really seem like a supported configuration.

BetaBlocker 0

As a general case, I think this is not a blocker. But I'm open to an argument that the impact for ARM devices is sufficiently broad to warrant blocking.

BetaBlocker -1
as for Adam's arguments

According to https://bugzilla.redhat.com/show_bug.cgi?id=1907030#c9 this breaks even with 1 GB RAM. Members from several teams voiced concerns. We don't have any exact numbers in the release criteria, but there are some numbers mentioned here:
https://docs.fedoraproject.org/en-US/fedora/latest/release-notes/welcome/Hardware_Overview/
It suggests 2 GB RAM as a minimum in general, but it also claims that for a minimum text installation, even less than 768 MB RAM should be doable. Perhaps we should update those numbers, or have a discussion about it.

Before making a call, I think the affected parties should clarify the impact this has on their Edition/Spin (e.g. how many ARM devices would we stop supporting) and see if there's some realistic fix we can do.

At this moment:
BetaBlocker 0

I agree with Kamil.

Punt for now.

punted

Discussed during the 2022-08-22 blocker review meeting: [0]

The decision to delay the classification of this as a blocker bug was made as this is a difficult call as it really depends on a subjective evaluation of how much RAM we're comfortable with requiring for basic packaging operations on a minimal Fedora environment. We will solicit input from various teams and re-consider this at a later time.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2022-08-22/f37-blocker-review.2022-08-22-16.01.txt

BetaBlocker -1

AGREED RejectedBetaBlocker

Discussed during the 2022-08-29 blocker review meeting: [0]

The decision to classify this bug as a "RejectedBlocker (Beta)" was made on the grounds it already affects F36 so blocking F37 on it doesn't achieve much. We also note no simple fix has been identified; fixing this may require a significant overhaul of DNF (which is already in the works as DNF 5). We note that it may be desirable to require the system requirements doc to be updated and possibly to include microdnf in installs likely to be used on.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2022-08-29/f37-blocker-review.2022-08-29-16.01.txt

The following votes have been closed:

• Rejected BetaBlocker (+0, 2, -4)
  • 0 by bcotton, kparal
  • -1 by jmracek, adamwill, geraldosimiao, jonathanspw

BetaBlocker -1

Release F37 is no longer tracked by BlockerBugs, closing this ticket.