Description of problem: There was a discussion on the packaging mailing list [1] regarding the mandatory dist tag [2] missing in certain packages. Those packages include: fedora-release-0:23-0.14.noarch fedora-release-cloud-0:23-0.14.noarch fedora-release-server-0:23-0.14.noarch fedora-release-workstation-0:23-0.14.noarch fedora-repos-0:23-0.3.noarch fedora-repos-rawhide-0:23-0.3.noarch generic-release-0:23-0.6.noarch generic-release-notes-0:23-0.6.noarch We would appreciate having dist tag really everywhere, because we can use it then in our automated testing to improve performance (instead of sending queries to Koji). It has been mentioned that fedora-release (and I assume generic-release as well) contains the definition of the rpm macro, and therefore can't use it. But it has been suggested that the package could hardcode the value instead of using the macro. Also, Vit Ondruch said: "There is %{load:<path>} macro in RPM [3] for some while already and instead of creating the macros.dist on the fly [4], it would be probably better to have it as a source, where the %dist tag is defined and just %load it into the fedora-release.spec." I wonder if we can improve the situation here - use the dist tag where possible (fedora-repos? fedora-release-*? generic-release-*?) and use a different approach in the rest (hardcoding, macro loading)? Thank you. [1] https://lists.fedoraproject.org/pipermail/packaging/2015-June/thread.html#10693 [2] https://fedoraproject.org/wiki/Packaging:DistTag [3] http://lists.rpm.org/pipermail/rpm-maint/2014-February/003659.html [4] http://pkgs.fedoraproject.org/cgit/fedora-release.git/tree/fedora-release.spec#n140
generic-release and fedora-release define the macros. and fedora-repos's version is tied to the release. adding teh disttag makes no sense fedora-release-23-0.14.fc23 fedora-repos-23-0.3.fc23 generic-release-23-0.6.fc23 to me looks weird and serves no purpose. I really feel this should be closed as wontfix or cantfix. The only reliable way to check where something was built from is to query koji, perhaps we can work together to make that work more efficiently. The rpms you are talking about here come from 3 different packages.
So IIUIC there's no issue with adding %{dist} to fedora-repos, but you don't like the look of the RPM files' names. fedora-release and generic-release would require some changes. Looking into fedora-release spec file [1], would something like this work? %define release_name Rawhide %define dist_version 23 %define bug_version Rawhide # Generate dist macros now so that we can use it right away %define fedora %{dist_version} %define dist .fc%{dist_version} Summary: Fedora release files Name: fedora-release Version: %{dist_version} Release: 0.14%{dist} <snip> # Set up the dist tag macros install -d -m 755 $RPM_BUILD_ROOT%{_rpmconfigdir}/macros.d cat >> $RPM_BUILD_ROOT%{_rpmconfigdir}/macros.d/macros.dist << EOF # dist macros. %%fedora %{fedora} %%dist %{dist} %%fc%{dist_version} 1 EOF This actually made the spec file even less error-prone, because now you need to edit the "23" number in just a single place, instead of two. If that doesn't work for some reason (I'm no RPM expert), what do you think about the proposed %{load:<path>} macro? > to me looks weird and serves no purpose The ".fcXX" suffix in the RPM file name doesn't look weird to me, because we have it in all other packages. I'd rather call it consistent. But personal views often differ. I agree that it serves no purpose for you as a package maintainer. But it serves purpose for our automated QA efforts, *if* we can rely on having it everywhere (except for a few possible exceptions, if it is technically impossible to do). Because packaging guidelines seem to require it, we're trying to make use of it. If it doesn't work or is unreliable in some cases, we're going to explore other paths. We're hardly going to beat string parsing performance though, every other idea requires us making a network request or downloading the RPM in question (if we managed to put this info into RPM headers). > The only reliable way to check where something was built from is to query koji I understand this is the only and ultimate verification method. There can be typos in the spec files, etc etc. But we might not need that level of reliability, and we might be OK with QA checks crashing on packages with broken spec files. What we struggle with, though, is performance and network stability. That's why we want to avoid making (tens of) thousands of calls every day which can possibly be avoided. I certainly welcome any discussion which can help us out in this area. > I really feel this should be closed as wontfix or cantfix. Let me ask you in a different way. If we added the dist tag to all or at least some (fedora-repos) packages, would it negatively affect them in any way? Is this more about "I'm maintaining these packages and I don't like the changes", or is there a technical reason to reject it? Thank you for clarification. Or, if you feel this would deserve broader discussion, can you please reply to the thread in the packaging mailing list (linked in description)? [1] http://pkgs.fedoraproject.org/cgit/fedora-release.git/tree/fedora-release.spec
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
the fedora/generic release packages and friends are special packages, they're the way they are for various reasons.
Peter, could you please elaborate on those reasons, and respond to proposals in comment 2? Thanks.
I'm sorry to reopen this, I'd really like to have reliable dist tag in all Fedora packages, I don't understand why this was closed so quickly and without much reasoning. I don't want this to fall through the cracks and get forgotten. Can we try to find a solution here?
This is not going to be fixed. there is a risk that things will get messed up and it would be an extra manual thing to do. as it is the thing that defines the disttag it seems reasonable that it not have one itself. additionally adding a disttag manually may break anaconda on livecds.