On 12/14/18 10:20 PM, Neal Gompa wrote:
On Fri, Dec 14, 2018 at 3:09 PM Igor Gnatenko
<ignatenkobrain@xxxxxxxxxxxxxxxxx> wrote:
That makes sense that we can do something like this from DNF code..
However, it would be kinda hard to do any dependency resolution
checks..
Although we already have one which is module(platform:$PLATFORM_ID)
which is automatically populated from os-release by libdnf. Which is
actually causing problems during upgrade.
I like both approaches.
Is there a reason stuff like this isn't available from RPM itself
somehow? It seems like it'd make sense to just make this available as
some kind of special Provides property, since RPM knows about it and
would allow for dependency resolution to not be dependent on DNF...
The general concept is similar to rpmlib() dependencies in that they're
only resolvable by a running rpm instance. Which creates a whole new
class of problems that didn't exist before.
Also the "stuff like this" is such a wonderfully blurry thing. If we
were to export system architecture, what does that exactly mean? Is it
whatever 'uname -m' returns? But what if running as secondary arch (eg
under setarch i686 on x86_64) - that doesn't actually make the system
i686 so it's probably not what you really want, at least not always.
And for buildrequires, you'd actually need that on the build target
arch, which could again be something else.
Failing that, since we apparently have this already for module()
Provides, could we do this for system-architecture() too? I'd rather
not mess with fedora-release for this...
Like Nicolas pointed out, the filesystem is already arch-specific so you
can use that, no need to muck with fedora-release. For the cases where
this works that is - building packages for secondary arch will run into
trouble with that.
- Panu -
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
