Comments (2)
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.
from createrepo_c.
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.
from createrepo_c.
Related Issues (20)
- [FIX] Build from 'master' branch is broken HOT 3
- `_XOPEN_SOURCE` define in `src/misc.c` seems extraneous
- Drop `--database` and `--no-database`, split?/drop `sqliterepo_c` HOT 5
- Sending SIGTERM to "createrepo_c --workers 2" sometimes leads to a crash HOT 6
- `--pkglist` can't be used with non-regular files
- Parsing primary.xml error: Start tag expected, '<' not found HOT 4
- heap buffer overflow and stack buffer overflow in test suite HOT 3
- Intermittent crash in `ci-dnf-stack/dnf-behave-tests/createrepo_c/zchunk.feature` HOT 1
- Python bindings fail to add the default version for sqlite records
- Has `--deltas` option been removed? HOT 9
- Brainstorm ways to shrink RPM metadata HOT 5
- Fix the building process to drop documentation for disabled features
- Newer createrepo_c doesn't generate comps readable EL7 HOT 27
- sqlite3_enable_shared_cache HOT 1
- `modifyrepo_c` and `mergerepo_c` generate `--no-pretty` metadata by default
- createrepo_c zstd compression doesn't fill in the content size, in the frame header. Python API problems. HOT 4
- Allow parsing packages metadata without filelists HOT 2
- cr_xml_dump_int() should point to a forbidden character HOT 2
- Removing older versions from the repo. HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from createrepo_c.