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

[Tomas Mlcoch]

A thought on a possible (future?) extension of the format.

Based on a remark from RPM team during a meeting some time ago, where they mentioned that lock file could serve as a manifest. I was thinking about that and in deed, "manifest" may be a nice potential use-case for the format.
(Just for context, right now, the main use-case for the format - if I simplify a lot - is to provide a list of RPM URLs that cachi2 needs to download for hermetic (container) build process and that's it.)

I think that if we add two more pieces of information for each RPM, then this format would be able to serve as a manifest quite well.

The two pieces of information would be:

- `name` (package name) - mainly for convenience, so consumer don't have to parse URL for that info.
- `evra` (epoch:version-release.architecture) - epoch is usually not part of the filename so without listing it in the file, it would be unknown.

Example of the extended format (btw. the order of attributes doesn't matter as these are dictionaries):

    lockfileVersion: 1
    lockfileVendor: abcde
    arches:
      - arch: x86_64
        packages:
          - url: https://mirrors.nic.cz/pub/fedora/linux/updates/38/Everything/x86_64/Packages/v/vim-enhanced-9.1.113-1.fc38.x86_64.rpm
            checksum: sha256:545d77bb579a8fb3e87ecd1d5acf616b4b837612f189206171edad73fd4864ab
            size: 1975462
            repoid: updates
            name: vim-enhanced
            evra: 2:9.1.113-1.fc38.x86_64
          - url: https://mirrors.nic.cz/pub/fedora/linux/updates/38/Everything/x86_64/Packages/v/vim-common-9.1.113-1.fc38.x86_64.rpm
            checksum: sha256:cce5fcc8b6b0312caeca04a19494358888b00c125747f5c2d2bd8f006665c730
            size: 8207912
            repoid: updates
            name: vim-common
            evra: 2:9.1.113-1.fc38.x86_64
    ... SNIP ...

These two new attributes would be necessary if someone wants to use the format as a manifest - because there is no guarantee that RPM filename in the URL would contain all the important information.
For example, a `foo.rpm` filename doesn't provide any info about epoch, version, release or architecture of the package, and there is also no guarantee that the actual name of the package is `foo`.
And because of ephemeral nature of some repositories and packages in them, it may not be possible to re-download the exact RPM later to read these metadata from the same URL. That's why I suggest this extension.

Btw. To illustrate the need for these, see the manifests used by coreos: https://github.com/coreos/fedora-coreos-config/blob/testing-devel/manifest-lock.x86_64.json

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

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