@Tojaj either that or just stuff a `type: (rpm|srpm)` attribute to the repo
object to make it clear upfront. The attribute could be optional defaulting to
'rpm' so you'd only ever need it for srpm to again avoid cluttering the file
with a supposedly redundant information in 85%~ use cases.
--
> Should there be a separate type for debuginfo though?
Yes, there should be.
> The type attribute is an interesting idea. If you had a repo that mixes both
> types of files, you would need to list it twice (each time with different
> type), but nothing about the format prevents that.
While
reason why I suggested using the keyword `rpms` everywhere is consistency from
the processor's perspective. While it surely could handle a change of keyword
for the same meaning a different attribute leads IMO to a cleaner design.
--
Reply to this email directly or view it on GitHub:
Looking at the lockfile format I can see a repeating pattern of:
```
- url: https://someurl
repoid: foo
- url: https://someotherurl
repoid: foo
- url: https://anotherurl
repoid: bar
```
IOW any tool which wants to process this has to analyze every single package to
categorize it under some
> @eskultety I have no problem with this, I would just suggest to keep sources
> as sources and not rpms, because then you would need a heuristic logic in the
> client consuming this format to detect sources (although it may be as simple
> as endswith((".src.rpm",".srpm")).
In hindsight the
No, declaring such a thing unsupported is IMO too harsh. Like I suggested
earlier, I would find acceptable assuming the default `type: rpm` in this case
(or maybe even `type: any`) in which case producers of such data must accept
the fact that by mixing multiple types of packages under a single
@Tojaj @lubomir @onosek I just read
this:https://github.com/rpm-software-management/dnf5/issues/833 which actually
pitched the idea of standardizing on the format across the whole RPM ecosystem
rather than letting other communities implementing similar idea from scratch
over and over again.
> 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
Just to keep this in sync what was discussed via a private channel, package
checksums (in some form) will need to be introduced to the format.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2908#discussioncomment-8527603
You are
> maybe ignoring the full URL just focusing on NVR
@voxik There are use cases where you cannot rely on packages residing in a
repo, e.g. a single 3rd party package hosted on a page somewhere in which case
you need a URL to get it.
--
Reply to this email directly or view it on GitHub:
> lockfileType - that distinguishes between rpms.in.yaml and rpms.lock.yaml)
I think this field is largely irrelevant since `rpms.in.yaml` is definitely
completely out of scope for this discussion (as this is just the basis for the
actual `rpms.lock.yaml`) as well as because it doesn't really
> If I did rpm -I vim-enhanced-10.0.038-1.fc38.x86_64.rpm, the command would
> fail, because the NVR does not match the lock file. If I did rpm -I foo, this
> wold also fail, because foo package is not listed in the lock file. But doing
> rpm -I vim-enhanced-9.1.031-1.fc38.x86_64.rpm would
Something that occurred to me just now - why does the lockfile contain multiple
architectures? Isn't a purpose of a more-or-less generic lockfile to address a
single use case? IOW the way I'm now looking at the format it looks like
whatever is consuming the lockfile is supposed to prefetch data
@lubomir while possible by the format I think having some semi-official
guidance on the problem would be preferred in that I'm personally not a fan of
redundancy - in this case specifying the same repo multiple times assigning a
different type to it each time. What it would inherently lead to
I think that in context of reproducibility and secure supply chain SW delivery
lockfiles as a concept makes sense and from my layman's perspective it looks
plausible however I don't feel competent enough to review this format in depth.
What I as a stakeholder am interested in knowing is the
15 matches
Mail list logo
