Bug 244057
| Summary: | dist tag should be defined by default | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Ray Strode [halfline] <rstrode> |
| Component: | comps | Assignee: | David Cantrell <dcantrell> |
| Status: | CLOSED RAWHIDE | QA Contact: | |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | rawhide | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2007-06-25 14:25:37 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Dist tag is defined in redhat-rpm-config. If they don't have redhat-rpm-config installed, then it will be undefined. Now, whether or not rpm-build depends on redhat-rpm-config is a different matter, and/or making redhat-rpm-config a default in some comps group. Thoughts? yea, we should get it fixed in comps I guess. This feels more like policy than anything, so comps seems better than a requires, imo. (although it probably doesn't really matter either way) (In reply to comment #0) > We should add a define to the default rpm config like > > %define dist .local > > or something similar so that rebuilds get a higher sorting dist tag than what > we ship prebuilt. So the first rebuild will produce a higher number but not subsequent ones? If you think rpmbuild should provide higher numbers, that's probably an RFE for rpm (though I think its wontfix), but not something we ought to fix artificially. Besides, I don't really think that users expect the number to be higher. They just want it to not be lower. right, just as long as dist is defined. That's all I really care about. it apparently is, it's just redhat-rpm-config isn't getting installed by default. So we need to fix that in comps, or with a Requires somewhere. (In reply to comment #4) > right, just as long as dist is defined. That's all I really care about. As an aside, it might be worthwhile to take your original local dist idea and stick into the .rpmmacros file generated by tools in rpmdevtools package as an instructive commented out line. -jef This is hardly the primary issue (I'm he who first brought this up on the fedora-devel thread). The primary issue is that the rpms I'm creating are named EXACTLY as those in the repository and newer than those in the repository, yet rpm is reporting the repo rpms as being NEWER. For example, download the gcc src.rpm and "rpmbuild --rebuild" it, no matter what %dist tag you put in an rpmmacro file, it will be stripped from the resulting package and you'll be left with rpms of the exact same name as the repo versions. automake is the same way - as well as quite a few others While this is obviously a packaging bug with these packages, rpm should still not be telling me that a newer version exists when it doesn't. If, for some reason, rpm prefers the repo rpm over the custom one, the error message should read accordingly, ie "we'd prefer you used the binary rpm for this...". As it stands, if I want to keep my custom install I have to either actually open the src.rpm and change the version or I have to manually install any other packages I may want (and considering gcc is doing this, that means practically any development packages/applications) and I can't use any sort of automatic updating. The original problem posted by Ray is somewhat annoying, but it's rather easy to work around for those packages that do conform and actually use the dist tag. My main problem is that core development packages like gcc, binutils and automake don't do this. Jesse: Dist tag is defined in redhat-rpm-config. If they don't have redhat-rpm-config installed, then it will be undefined I had it installed and there was no value set here. rpmdevtools is dependent on this package. I'm of the mind it should be defined with something like "999.username" though just to make it easier on the end user - if they so desire, they can go change that to something else and it would make it possible for them to avoid this problem on most packages. All of this started out as a bug in rpm reporting older rpms as being newer - more specifically, in rpm making preference for repo rpms over custom rpms of the same name and version with newer build times - so even if there was an "fc7" dist tag installed, it wouldn't fix the issue. All in all, there are actually at least this bug with rpm and a bug for each package that doesn't utilize the dist tag properly. Hi,
If you rebuild a package that doesn't have a %{?dist} suffix in it's Release
field, the resulting package will have the same version as the package in the repo.
If you try to install the rebuilt package, it won't say the repo package is
newer. It will say it's the same version. Something like "package
gcc-the-version-here is already installed". You can make it do it anyway by
passing --replacepkgs to the command line during the install process.
It doesn't look at build time/date at all when deciding which package is newer.
dist tag is now defined in /etc/fedora-release package in rawhide. This is the most logical place to put it as fedora-release defines other parts of the release on the system. |
right now if a user does a local rebuild of an srpm we ship, they end up with a package that has a /lower/ version than the shipped version because most packages do Release: 1%{?dist} and dist is defined to ".fc7" or whatever in koji, while it isn't defined at all on the local machine. We should add a define to the default rpm config like %define dist .local or something similar so that rebuilds get a higher sorting dist tag than what we ship prebuilt.