On Thu, Jun 18, 2015 at 12:13 PM, James Antill <james@xxxxxxxxxxxxxxxxx> wrote: > On Wed, 2015-06-17 at 13:27 -0400, Matthew Miller wrote: >> On Tue, Jun 16, 2015 at 10:44:26AM -0400, Martin Krizek wrote: >> > According to [1], using a dist tag is mandatory. However there are quite a few >> > packages [2] where a dist tag is missing. I am curious if those are bugs and >> > should be filed. Or are there any exceptions that I am missing? >> >> Soooo, going back a level... I see that there is a "DISTTAG" in RPM >> headers, but it's not set to anything in any of my installed packages. It's typically set for the build environemnt in /etc/rpm/macros.dist. That's built as part of the 'fedora-release' or similar OS release packages, and that seems a perfectly safe package to build up from a previous build environment first as part of the bootstrap process for new releases. >> What if we actually set this in the build system, and removed it from >> the Release field in all of our specfiles (with one big recursive sed >> script)? The filename generation could be changed to automatically add >> this, and query and sort operations also adjusted appropriately. > > 1. Then you need to fix rpm/yum/dnf/libsolv to honor it for upgrades. > > 2. Then you need to fix rpm/yum/dnf/libsolv to parse it out of the > specfile and honor it for conflicts/obsoletes/provides/requires. Why? If you're activating a dnf or yum repository for desired access, why would you want to segregate the 'dist' from other alphhanumeric fields? If you activate both Fedora 21 and Fedora 22 in your configs, for whatever reason, it's normally reasonable to assume that a .f23 is more recent and usable than a .f22. It's only when updates or significant renaming exist for older operating systems than for newer operating systems, and you *cannot* hope to outsmart this kind of chaos. Attempts to outsmart this are, generally, doomed to failure becuase you cannot go back to old packages and make them be rebuilt with whatever hacked up workaround comes with newer versions. > 3. Then you need to fix createrepo/createrepo-c, and the repodata, to > work with #2. Why? Why would you *ever* want to play max and match with multile 'dist' ettings in the same repository, and *not* obey normal dist versioning? > 4. Then you need to fix yum/dnf/etc. to optionally parse it out of the > command line. > > 5. Then you need to fix koji. > > 6. Then you just need to fix the rest of the world. Again, why? This is normally *set* by the 'fedora-release' package. which should be one of the first packages built in the bootstrap procedure for new releases and can reasonably safely be bootstrap built. And it gets a major version version number update anyway, so it's not like there will be conflicts. -- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
