Xose Vazquez Perez wrote:
> BAD use of %{dist} tag(75):
> ==========================
> afpfs-ng-0.8.1-13.fc21.3.src.rpm 13.fc21.3
[and many similar examples]
NOTABUG: https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Minor_release_bumps_for_old_branches
(the next paragraph right after the one you linked to).
> dcm4che-test-2.6-0.8.fc20.20110530svn15516.src.rpm 0.8.fc20.20110530svn15516
> mediatomb-0.12.1-31.fc21.20120403gitb66dc1.src.rpm 31.fc21.20120403gitb66dc1
> unhide-1.0-10.fc20.20121229.src.rpm 10.fc20.20121229
These ones are actually wrong (the alphatag should come before the disttag).
> html401-dtds-4.01-19991224.12.fc20.4.src.rpm 19991224.12.fc20.4
This one is also wrong, but not because of the disttag. The date should come
after the 12. But fixing it is not doable (without an ugly Epoch bump),
unfortunately. So IMHO it should just stay as it is now.
> keurocalc-1.0.0-2.rc2.fc20.7.src.rpm 2.rc2.fc20.7
> python-gevent-socketio-0.3.5-2.rc2.fc20.1.src.rpm 2.rc2.fc20.1
> python-rhev-1.0-15.rc1.fc20.4.src.rpm 15.rc1.fc20.4
Likewise, 2.rc2 makes no sense, it should be 0.2.rc2:
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packages
but here too, fixing it would require an Epoch bump.
> ocaml-omake-0.9.8.6-0.rc1.fc21.8.src.rpm 0.rc1.fc21.8
Another violation of:
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packages
The incrementable integer between 0 and rc1 is missing here. But again, not
fixable without an Epoch bump.
> plexus-mail-sender-1.0-0.a2.24.fc20.1.src.rpm 0.a2.24.fc20.1
Alphatag before incrementable integer. See html401-dtds. Not fixable without
Epoch bump.
> speed-dreams-2.1.0-15.trunk_r4810.fc20.3.src.rpm 15.trunk_r4810.fc20.3
trunk_r4810 is not a valid alphatag, it should be 20YYMMDDsvn or
20YYMMDDsvn4810, at the packager's discretion. This one is fixable (just
bump the 15 to 16). Though if this is actually a pre-release rather than a
post-release, it should actually be 0.15.… and that cannot be fixed without
an Epoch bump.
It's incredible how many instances of invalid pre-release versioning we
have. Those guidelines are very important because they avoid useless Epoch
bumps, and thus it is all the more important to get them right the first
time (because if you screw up, you usually cannot fix it without bumping
Epoch). And these are only the ones that happened to have something after
the disttag, there must be many more instances that your script didn't
catch!
> These aren't bad formed. And even it's not mandatory,
> but %{dist} allows more flexibility in the handle of
> the packages/distribution.
>
> NO %{dist} tag(42):
Well, as you say, it's not required. Maybe we should require it. (Our
aggressive mass-rebuilding and the demise of the old hacks to hardlink data
packages in the repos from one version to the next and of Rawhide
inheritance kinda make the points which spoke against it moot.) But as long
as we don't, you can't blame packagers for not using it.
Kevin Kofler
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
