how does src rpm by pass sub packages in conditons
wswsmao opened this issue · 2 comments
Hi, @ppisar
I encountered a confusion recently.
This is my spec:
%ifarch x86_64
%bcond_without mssql
%else
%bcond_with mssql
%endif
...
%if %{with mssql}
%package pmda-mssql
...
%endif
Apparently, we cannot get the pmda-mssql subpackage under the aarch64 architecture
however，the repodata of src package in all architectures is this:
<rpm:entry name="pcp-pmda-mongodb" flags="EQ" epoch="0" ver="6.0.5" rel="6.ocs23"/>
<rpm:entry name="pcp-pmda-mssql" flags="EQ" epoch="0" ver="6.0.5" rel="6.ocs23"/>
<rpm:entry name="pcp-pmda-json" flags="EQ" epoch="0" ver="6.0.5" rel="6.ocs23"/>
conditons build can not be recognized, and pmda-mssql will be queried in no-x86_64.
I was wondering is there any way to recognize conditons build? I would be honored to submit the code for this feature.
As you correctly find out, dependencies of source packages vary among architectures. In other words, a source package is specific to the targeted architecture. However, distributions, like Fedora, ignore this fact and to safe space and time they produce a single source repository from source packages randomly built on different architectures. That's the root cause and as a result the output source repository is not accurate.
With the current technology, the only way how to obtain accurate source repository is to rebuilt all source packages on given architecture and then make a repository from them. (If you want to do that for multiple architectures, you will end up with multiple source repositories.)
There is no standardized way how to write and thus recognize a build-time condition. All the spec macros as %bcond, %bcond_with expand to a %if condition. (Another popular build condition is define e.g. "%java_arches aarch64 ppc64le s390x x86_64" in /usr/lib/rpm/macros.d/macros.java-srpm, which is preinstalled in a machine building source packages, and then use "%ifarch "%java_arches" in spec files.) Therefore the only is to evaluate the spec file in a controlled environment, i.e. to build the source package, on concerned architectures and then compare the packages each to other.
Because this task requires the controlled environment (e.g. a chroot with an installed minimal build root), it is not feasible for createrepo_c to support this feature on its own. It's better to rebuild the source packages externally, and then run createrepo_c on them.
The only thing I can imagine being useful, would be enhancing primary.xml format with e.g. a "target-arch" attribute:
<rpm:entry name="coreutils"/>
<rpm:entry name="pcp-pmda-mongodb" flags="EQ" epoch="0" ver="6.0.5" rel="6.ocs23" target-arch="x86_64"/>
That way a single source repository could accurately store dependencies for multiple architectures. However, primary.xml now contains data like hashes of the packages, and those would differ. That means primary.xml would have to be stripped from the hashes. That makes such repository less helpful.
I guess that's the reason why the repository format does not support it. At the end it's easier to produce multiple repositories for multiple architectures and save a disk space by sharing identical packages among the repositories (by symlinks or href attributes).
Overall I recommend to not touching createrepo_c regarding this topic at all and closing this ticket.
As you correctly find out, dependencies of source packages vary among architectures. In other words, a source package is specific to the targeted architecture. However, distributions, like Fedora, ignore this fact and to safe space and time they produce a single source repository from source packages randomly built on different architectures. That's the root cause and as a result the output source repository is not accurate.
With the current technology, the only way how to obtain accurate source repository is to rebuilt all source packages on given architecture and then make a repository from them. (If you want to do that for multiple architectures, you will end up with multiple source repositories.)
There is no standardized way how to write and thus recognize a build-time condition. All the spec macros as %bcond, %bcond_with expand to a %if condition. (Another popular build condition is define e.g. "%java_arches aarch64 ppc64le s390x x86_64" in /usr/lib/rpm/macros.d/macros.java-srpm, which is preinstalled in a machine building source packages, and then use "%ifarch "%java_arches" in spec files.) Therefore the only is to evaluate the spec file in a controlled environment, i.e. to build the source package, on concerned architectures and then compare the packages each to other.
Because this task requires the controlled environment (e.g. a chroot with an installed minimal build root), it is not feasible for createrepo_c to support this feature on its own. It's better to rebuild the source packages externally, and then run createrepo_c on them.
The only thing I can imagine being useful, would be enhancing primary.xml format with e.g. a "target-arch" attribute:
<rpm:entry name="coreutils"/> <rpm:entry name="pcp-pmda-mongodb" flags="EQ" epoch="0" ver="6.0.5" rel="6.ocs23" target-arch="x86_64"/>That way a single source repository could accurately store dependencies for multiple architectures. However, primary.xml now contains data like hashes of the packages, and those would differ. That means primary.xml would have to be stripped from the hashes. That makes such repository less helpful.
I guess that's the reason why the repository format does not support it. At the end it's easier to produce multiple repositories for multiple architectures and save a disk space by sharing identical packages among the repositories (by symlinks or href attributes).
Overall I recommend to not touching createrepo_c regarding this topic at all and closing this ticket.
Ok, I get it.