Re: Expansion of rpmautospec macros when building new packages

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Dne 05. 11. 21 v 15:12 Ankur Sinha napsal(a):
On Fri, Nov 05, 2021 14:51:44 +0100, Miro Hrončok wrote:
On 05. 11. 21 14:13, Ankur Sinha wrote:
Hi folks,

I've been working with a few Outreachy candidates to help them learn
packaging.  We're using `fedpkg` as much as we can, since it's what we
use to work with all packages after they're imported into Fedora.

So, we first create git repo to work in, and after we write the spec,
we iteratively use `fedpkg mockbuild` to run mock and test builds before
running rpmlint and so on and submitting the package for review. Here, I
noticed we get an srpm which contains the spec where the `%autorelease`
and `%autochangelog` bits are already expanded.

This is causing a couple of issues with reviews and imports:

- this spec in the srpm now differs from the spec, and fedora-review
    will flag this difference---which is confusing for newcomers (and had
    me confused for a bit too)

- after the review, when `fedpkg import` is used to initialise the SCM
    using the approved srpm, again this spec with `%autorelease` and
    `%autochangelog` already expanded is pulled in. Here's an example of a
    package we only imported recently where we didn't realise this:
    https://src.fedoraproject.org/rpms/python-glymur/blob/rawhide/f/python-glymur.spec

This isn't necessarily a problem from a technical perspective, but it's
a little annoying that one now has to remember to manually revert the
spec back to use the macros before committing to SCM. If one has to
manually tinker with the changelog etc., it defeats the purpose of the
macros.

Since we didn't realise this, the package is now not using
`%autochangelog` and the first build has a release value that isn't 1:
https://koji.fedoraproject.org/koji/packageinfo?packageID=34682

So we'll need to fix it (more work):
https://docs.pagure.org/fedora-infra.rpmautospec/opting-in.html#for-existing-packages

So, can anything be done to make this workflow better? Should we/can we
disable these when using mockbuild, or add an option to do so that can
be used for new packages to keep the value at 1? Or do we note that
these macros should only be used right before import (but that means
again editing the spec after running `fedpkg import` and more confusion
for newcomers)?
The %autorelease/%autochangelog macros assume we are in a git repository.

Hence if the package is created in a git repository before it is imported
into Fedora, we should probably teach the packagers to push those commits to
Fedora when he package is approved, instead of using `fedpkg import` which
will also throw away their git history.
Hrm, but how would we do this? The new SCM repo that is created has a
completely different commit tree. I guess we can add the new remote and


And then rebase. This is script I use:


~~~

#!/bin/sh

git checkout main

git remote set-url origin ssh://vondruch@xxxxxxxxxxxxxxxxxxxxxx/rpms/"$@"
git fetch origin

git branch main -t origin/main
git rebase origin/main

~~~


Vít


Attachment: OpenPGP_signature
Description: OpenPGP digital signature

_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux