Due to this: Obsoletes: mktemp Provides: mktemp = %{version}-%{release} coreutils now obsoletes itself. Also, mktemp had an epoch, which needs to be preserved. See the "Renaming or Replacing Existing Packages" section of http://fedoraproject.org/wiki/Packaging/NamingGuidelines This looks correct according to the above guideline: Obsoletes: mktemp < 3:1.5-26 Provides: mktemp = 3:1.5-27 The last version of the mktemp package in rawhide was 3:1.5-25, so obsolete everything less than 3:1.5-26 and provide something slightly larger than that. Of course, if the version in F7 or F8 gets updated, it will need to use sub-revisions (1.5-25.fc8.1) or you'll have to change these to maintain the upgrade path.
Thanks for report ... will fix that soon - anyway I have to speak with current mktemp maintainer about the situation and possible removal of the mktemp package from rawhide...
One of the possible solutions is epoch increase in the mktemp Provides in coreutils as it has completely different version than the mktemp upstream, which is independent on coreutils.
(just want to mention that completely different but 100% compatible) I see following solutions: 1) The one suggested by jnovy in comment two (to use Obsoletes: mktemp < 4:%{version}-%{release} , Provides: 4:%{version}-%{release} - as this is different implementation, coreutils mktemp version is completely different than upstream (0:6.10 - coreutils, 3:1.5-25 - BSD mktemp upstream) ) 2) To not ship coreutils mktemp and use the old mktemp (and no Provides/Obsoletes: mktemp) As the last upstream version is more than 4.5 years old I would prefer the first one - as GNU coreutils upstream is much more active. (adding mktemp fedora maintainer to cc)
Used solution #1 in coreutils-6.10-2.fc9 ... closing RAWHIDE, feel free to add comments here, but I think that mktemp drop discussion is in bugzilla #226147 and non-versioned obsolete problem was fixed now.