Bug 244057 - dist tag should be defined by default
dist tag should be defined by default
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: comps (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: David Cantrell
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-13 11:08 EDT by Ray Strode [halfline]
Modified: 2013-01-09 20:39 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-06-25 10:25:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ray Strode [halfline] 2007-06-13 11:08:02 EDT
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.
Comment 1 Jesse Keating 2007-06-13 11:19:41 EDT
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?
Comment 2 Ray Strode [halfline] 2007-06-13 11:28:01 EDT
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)
Comment 3 Christopher Aillon 2007-06-13 11:35:00 EDT
(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.
Comment 4 Ray Strode [halfline] 2007-06-13 11:51:10 EDT
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.
Comment 5 Jef Spaleta 2007-06-13 12:53:20 EDT
(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
Comment 6 J French 2007-06-13 22:56:02 EDT
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.
Comment 7 Ray Strode [halfline] 2007-06-14 10:33:09 EDT
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.


Comment 8 Jesse Keating 2007-06-25 10:25:37 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.