| |
@@ -30,3 +30,26 @@
|
| |
:ref:`using-autorel`. So before `rpmautospec` is deployed in production,
|
| |
these use cases should be fully implemented.
|
| |
|
| |
+ * Currently, running ``fedpkg`` on a package that has opted in on `rpmautospec` leads
|
| |
+ to warnings and error messages such as these::
|
| |
+
|
| |
+ warning: line 12: Possible unexpanded macro in: Release: %autorel
|
| |
+ warning: line 12: Possible unexpanded macro in: Release: %autorel
|
| |
+ warning: line 39: Possible unexpanded macro in: Provides: python-arrow = 0.14.6-%autorel
|
| |
+ warning: line 39: Possible unexpanded macro in: Obsoletes: python-arrow < 0.14.6-%autorel
|
| |
+ error: %changelog entries must start with *
|
| |
+
|
| |
+ Before `rpmautospec` is made generally available, we should improve ``fedpkg``
|
| |
+ to ignore these warnings/errors.
|
| |
+
|
| |
+ * The Koji builder plugin of `rpmautospec` currently installs ``rpmautospec``
|
| |
+ (the package containing the CLI tool) in the mock chroot if the packager has
|
| |
+ opted in for this package. This means that an additional yum/dnf transaction
|
| |
+ is performed, which slows down the build a little bit, but only affects
|
| |
+ packagers who have opted in. Alternatively, ``rpmautospec`` could be added
|
| |
+ to the list of packages Koji installs in the build root for building SRPMs.
|
| |
+ This would install all the packages in one transaction but adds
|
| |
+ ``rpmautospec`` to the build root even if it's not needed. It would be good
|
| |
+ to figure out the preferred approach for this before `rpmautospec` is
|
| |
+ deployed in production (and potentially adjust the Koji hub plugin
|
| |
+ accordingly).
|
| |
Signed-off-by: Pierre-Yves Chibon pingou@pingoured.fr