[Rpm-maint] [rpm-software-management/rpm] Introduction of "rpms.lock.yaml" file (Discussion #2908)

[Erik Skultety]

> Building a container for multiple architectures is single use-case, actually a use-case that will be more and more common because x86_64 arch domination is shifting (wide adoption of ARM, rise of RISC) so multi arch builds are must have and consistency between arches is desired. I don't think this is (and ever was a private use-case).

I never argued against multiple architectures...

> If you want to have separate arches, it can be still easily done, current format doesn't block this in any way. Frankly it also feel more natural to have architecture listed in the file directly rather then encoding it into the filename, where it may get lost if you share just the file content (e.g. sharing by sharing file content via paste-bin or GitHub Gists).

...nor did I suggest encoding the arch into the file name. 
I only commented on the fact that we're treating the lockfile not as an input for a single operation, but from what  I can see - a batch operation, IOW use a single lockfile for a single artifact prefetch which will then be re-distributed among multiple concurrent arch builds of the same container. My only argument revolves around let's call it "pipeline encapsulation", meaning that there should be a single architecture prefetch for a single container build (again, we're getting too specific in the overall use case of the lockfile as proposed, but okay). So, yes, the current format doesn't block single arch use cases, however, I wonder if more than a single arch (doesn't matter which one, the lockfile would tell you that with an attribute)in the lockfile is a desirable design.
Let me elaborate on this some more so that it's clear why I'm even poking it.
As you propose, sources would be tied to architecture, however, that's not always the case (e.g. Fedora) so from that perspective sources should be modeled outside of a given architecture, but that's a Fedora policy, not a DNF constraint, so some sources will be architecture-dependent and some won't which naturally leads to a split design of how source RPMs should be modeled in the YAML depending on what distro and arch you use. Conversely, if you only ever allow the lockfile to describe a single architecture instead of batching, it doesn't matter because you'll only ever process a single architecture, so you'd always model sources the exact same way whether they're tied to an architecture or not, it would be modeled as just another repo like all the others, it would just happen to be for srpms. Maybe I'm being naive but it would IMO simplify the design some more without sacrificing too much on the pipeline use case, you'd just need to have multiple lockfiles stored (one per arch) which to me sounds like a reasonable tradeoff.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2908#discussioncomment-8527430
You are receiving this because you are subscribed to this thread.

Message ID: <rpm-software-management/rpm/repo-discussions/2908/comments/8527430 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20240220/09616eb7/attachment-0001.html>