-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Sat, 2017-09-02 at 15:06 -0400, Rob Marshall 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/ Then it is simply wrong 😉
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?
You *can't* find any packages by *basearch*, you can find
packages only
for *arch*.
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
_______________________________________________
rel-eng mailing list -- rel-eng(a)lists.fedoraproject.org
To unsubscribe send an email to rel-eng-leave(a)lists.fedoraproject.org
- --
- -Igor Gnatenko
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlmrr6UACgkQaVcUvRu8
X0zjCg/5AdtNXCNviI6ZU1jl2tnYKaETS+PixDEhcTUCUuh+VWiG29I1lkSX/QpX
uWg6ksOI4tDYGbDTirrbBU6QLk9mHgo0Te622Ht+00CwJzcblMziLBbeRjlRLlJ3
h+zopqcFUe887Q7FSaLcBefk5TWUX87cF27Zq5Q/wtPiEJ8NQmBLWecI8bnodOJB
hMhLtfLLis6eGBq0onBQa3uRZq8Nszvr8mmMN1QQl4C8WCVzi5k+ie/CbAlki6gX
WuiNRs4vgi+JkT/hZg6mQ9rMmMeoZs7hE9ZQ2W44fAi47ir14pITOw9RWo5QQTIZ
holdZcJJRLMJ7JhZv5PpgJTnrmRwjxPbn32Y5lkjmE6wgn8Nmy7HxAlrgqCwRi93
xJWAjjotXgi+XLCXVsOIVz0xASstj0P0hqPJcvayzRzKagvzn2bxkdcHdPsUXRhv
D2QOP3AjAAJ3OJNqNLtGxBdWNoxrVwWyoTxcAh/ExBjZtOf5mgrCj7tdyuhFSoi4
pnwdkRykyU4qcFE/KACSb4L/NUwAL1g76vm7zMUz1HxSJ9fy/8DlkPNFiA4QpLhi
9HR8Zm85BeC3Ft6Waeh+tNTauCMTVIBWxDG6QYEiQWhQhUkV+oNWTNx6uGxhbCEg
mG5Ynv9+bx7qbNp4AjWksQjTxGD2tz/m4c9oM31kH61fSnx5Qpg=
=r/8a
-----END PGP SIGNATURE-----