package-cleanup-service

Created 6 years ago
Maintained by tibbs
We will help you clean up your packages!
Members 5
dmalcolm committed 6 years ago

Package Cleanup Service

Life has more meaning when we do the cleaning!

Package maintenance is bad enough, but those pesky packaging guidelines keep changing! Who has the time to keep up with all of that?

If you have a crufty old specfile and you've given up even looking at the rpmlint output, why not let us give it a good cleaning? Just open a new issue here and give us a few pieces of information and we'll take a look.

You should tell us:

  • Which Fedora package you would like for us to look at.
  • Which releases of Fedora and EPEL you would like for the specfile to cover.
  • Whether it is OK for us to clean up whitespace. Trailing whitespace will be removed, but we can also remove tabs and reindent things if you wish.
  • Anything you'd like for us to handle specifically, or that you'd like us to avoid touching.
  • Other additional information you'd like for us to know.

We will fork your package and send one or more pull requests against the master branch when done. You should inspect them and merge or not as you wish. We will have at least done mockbuilds but you should do all appropriate testing before pushing changes.

For those who wish to do cleanup

Anyone is welcome to join up to assist with cleanup. Thanks to the magic of Pagure, you won't actually need any commit privileges do to cleanup; you'll be forking and sending pull requests instead. You should, of course, know how to drive Pagure and git in order to do that. You should also have a firm grasp of packaging and the current state of the packaging guidelines, and be able to reasonably run mock, or be able to do koji scratch builds.

Then just ask for permissions on this repository so that you can take tickets, and start working on packages.

Style guidelines

It would be helpful to have some guidelines for style which go beyond what's in the guidelines. I (tibbs) have been working on some on and off for a while, but there is no chance that everyone can agree on all of them. In any case, here are some basic things:

  • Try to keep related changes in single, separate commits. So make whitespace changes separate from other changes, for example.
  • Remove all trailing whitespace.
  • No tabs; use plain spaces everywhere.
  • Use four space indentation if reindenting.
  • It is not necessary to align the specfile headers, but try to keep with what the spec originally used if possible.
  • Use %{buildroot} and %{optflags} in preference to $RPM_BUILD_ROOT and $RPM_OPT_FLAGS if there is any question about which should be used, but otherwise be consistent with the spec. Consider sending a separate PR to switch to the preferred method.
  • Remove all outdated sections and headers (%clean and Group: and the like).
  • Fix up any uses of %define which should be %global. (The difference is subtle; if in doubt, ask in the ticket.)
  • Use curly brackets ({ and }) around macro names where generally used, unless the person requesting cleanup asked for them to be removed. Personally I (tibbs) can't stand them but many people are used to seeing them in some places (%{buildroot}) and not in others (%configure, %autosetup).
  • Use the shortest reasonable path macros (%{_var} instead of %{_localstatedir}, and %{_etc} once we have it).
  • Always run rpmlint (preferably within the editor after a quick inspection for safety) and do reasonable cleanups.
  • Try to convert to %autosetup -p1 but ask first if this means regenerating patches.
  • Reorder sections to the usual order if necessary, but do it up front in a separate commit. (Need to document what this order actually is.)
  • Increment the package Release:.
  • Definitely credit yourself in a changelog entry.