Rpmautospec known issues, yet default in F38?

Project Discussion
1

I kind of tripped upon this when updating a package that was using rpmautospec. I then learned, that rpmautospec was approved for F38 default by FESCO two months ago, yet rpmautospec breaks fedpkg import srpm. A fix was proposed, but has not been implemented, nor has mitigation been documented AFAIK. I created a bugzilla ticket, and the response so far is crickets. Notwithstanding the fact that this change basically is suppose to relieve the packager from having to update 2 lines in a spec file, it replaces that by requiring an update of an external change file and breaks fedpkg functionality. So I don’t quite understand the compelling reason for this change. Placing that aside however, I don’t think it is wise to make default something that breaks existing processes without at least documenting a mitigation and/or fixing the issue. Does anyone have any updates on this?

2

It does more than “relieve the packager from having to update 2 lines in a spec file”—one doesn’t have to ever duplicate a changelog entry in the spec and the git commit.

I’m not bothered either way—I’m happy with either method. I’d discussed this on -devel and then we’d filed these issues to update docs:

https://pagure.io/fedora-docs/package-maintainer-docs/issue/52

Eventually, I wrote this up for our Outreachy candidates sometime ago to help them import their new packages:

https://pagure.io/fedora-docs/package-maintainer-docs/issue/56

1 Like
3

As I understand it the changelog file is a new construct that gets uploaded, where previously it was just in the specfile, so you have to update that now where as before you didn’t. I still don’t understand the compelling reason for this since you’re not really saving any effort, and if you are it is trivial. Plus the fact you’re breaking fedpkg update. Thanks for creating the mitigation workflow, but seems to me that the mitigation provided is alot more work that simply entering “fedpkg import srpm” - and for what, to save updating two lines in a spec file?

In any event, I’m a bit dismayed that FESCO approved this to be the default method and according to the tickets you filed we’ve known about this for over a year and it still isn’t fixed nor documented and F38 is around the corner.

Yes, I know many of us who contribute are volunteers, but people who are championing a change are responsible for following through and making sure everything is in place. If they need more time then the change should be delayed. I would think that 1 year would be more than enough time.

4

No, this is not how it is. A separate changelog file is only used when migrating to rpmautospec:

https://docs.pagure.org/Fedora-Infra.rpmautospec/opting-in.html#for-existing-packages

So, once a package has been moved to use rpmautospec, one does not need to use a changelog any more—one just adds the git commit message and that’s used automatically as the changelog entry.

I agree that the workflow should be fixed. I see there’s some discussion on the ticket you noted, so hopefully it’ll be done soon.

2 Likes
5

I see that the fedpkg import issue you’re concerned with is mentioned in the change proposal, so it’s on the radar to get addressed. And, the change is by default, not required for everything. So it’s okay if some corner cases are not immediately covered.

2 Likes
6

Thanks Matt, but I get a bit concerned when change proposals are approved and implemented with open existing issues which seem to languish for months and in this case a year and counting. I encountered this issue because I was addressing a bug on a package that had already been converted. I trudged through it since I was the one who had the historical knowledge of the issue. So while I agree it’s ok to conditionally implement, there needs to be some type of accountability for follow-thru.

7

Thanks very much for the reply. I’m not against this type of automation. The thing that is bothering me was this is an acknowledged, known issue and it seems to be languishing. I’m just trying to shine a light on it so it gets some traction.

8

Hmmm — I’m not really sure I agree with Vit’s suggestion for the workflow for updating a package. It seems a bit convoluted to me, when compared to just using fedpkg new-sources. Here’s what I do (with rpmautospec in place):

  1. Update the Version field in mypackage.spec to new version.
  2. Run rpmdev-spectool --sources mypackage.spec to download the new upstream source (this uses the URL configured in the specfile and therefore tests that that’s still right)
  3. Verify that the downloaded tarball is correct (check signatures, etc.)
  4. Do a mock build on my machine, and try basic functionality tests.
  5. Fix any problems, add patches, update specfile, etc.
  6. Repeat 4-5 as needed
  7. git add mypackage.spec
  8. fedpkg new-sources mypackage-#.#.tar.bz
  9. git commit (could skip step 7 and do git commit -a here, but I think this is safer)
  10. type in changelog
  11. git push
  12. fedpkg build
  13. come back later and if there’s a problem (like i tfails to build on s390x or something) go back to step 4.
  14. Go to bodhi and make an update.
9

You could also look at Packit, which automates most of this.

10

Also, I think the change doesn’t really explain the benefit well. Sure, it reduces a little duplication and saves a trivial update to Release, but the big benefit is that it removes what were previously unavoidable merge conflicts.

Let’s say, for example, that I go on vacation during what turns out to be a busy week. When I return, I discover:

  • there is a pull request waiting from someone who has updated the license field
  • there is another PR from someone who had added a patch to fix a bug
  • release engineering has done a mass rebuild

Now, if the PRs ignore the release and didn’t add a changelog, they can probably be merged with no problems — but then I need a new changelog entry explaining that I’ve merged these and what they did. But probably both increased the release number and added a changelog entry. These now both conflict with the update for the mass rebuild, and with each other.

With rpmautospec, assuming the actual change doesn’t conflict, these can all just be merged, and all will get a changelog entry and everything will just work.

1 Like
11

Yeah, I had an issue using git add and fedpkg new-sources years ago here is the lengthy discussion on the mailing list. I’ll give your workflow a try when I do my next update, and I’ll also take a look at Packit. Since we do fedpkg xxx it would be nice to have everything front-ended by that command rather than switching back and forth between fedpkg and git.

12

100%. Everything seems to be focused on the benefit of not having to update 2 lines.