On Sat, Sep 2, 2017 at 3:06 PM, Rob Marshall <rmarshal(a)redhat.com> wrote:
On Sat, Sep 2, 2017 at 2:46 PM, Neal Gompa <ngompa13(a)gmail.com>
wrote:
>
>
> You're doing the wrong thing. DNF has two properties you can use:
> "basearch" and "arch". If you set the "arch" correctly,
it will
> resolve the "basearch" automatically. The reason it works with x86
> arches is because the base arch is part of the arch name, which
> appears to validate the incorrect assumption that base arches are
> real. They are not. What you need to do is set the "arch" option to
> the real architecture (i.e. the architecture rpm builds for) and let
> it figure out base arch for you.
Given this information - what causes armv8l to only return 3 packages
despite being defined by DNF?
The PDC API seems to provide a list that supports using the armv7hl
architecture name, however, the i686 architecture is not present even though
it returns a list of packages:
https://pdc.fedoraproject.org/rest_api/v1/arches/
There is a hack in the old YUM method that manually assigns an architecture
name and, given all the information already in this thread, I can now see
why it was probably put into place at the time. What's our most accurate
method for programmatically determining a single valid architecture to use
for obtaining the critical path packages within a given base architecture?
Additionally - it's my understanding that critpath is used to populate some
data into PDC. It may not overlap, but does that pose any dangers of
creating a dependency loop?
--Rob
I actually would expect it to return no packages. The solver doesn't
know what armv8l even is[1]. I'm a little surprised it returned you
anything.
[1]:
https://github.com/openSUSE/libsolv/blob/master/src/poolarch.c#L23-L61
--
真実はいつも一つ!/ Always, there's only one truth!