#657 Keeping packager tooling in sync with our guidelines
Closed: nothingtodo 4 years ago Opened 5 years ago by tibbs.

I hesitate to open another ticket, but we should talk about this formally.

I did two things yesterday I haven't done in a long time: do a complete package review and create a new Perl package. This led to me off to file some bugs, because:

  • fedora-review gave incorrect information (in my case, complaining that BR: gcc-c++ was unnecessary and providing an incorrect link)
  • cpanspec generated a spec that didn't have BR: perl-generators and also things in the spec that haven't been needed since RHEL4.

We should think about how FPC relates to those tools. At minimum I guess bugs need to be filed when the guidelines change in such a way that those tools would need updates, but I'm not sure that's manageable. I'm not really sure if there's any good solution, but there must be something that's better than what we do now (which is nothing).

An incomplete list of stuff:

  • rpmdev-newspec - the templates are pretty far out of date.
  • rpmlint - Really needs a big review. Definitely needs to grow some complaints.
  • cpanspec - even ignoring the old cruft, really needs to add the perl-generators stuff.
  • fedora-review - Should probably be checked over closely.

I'm sure there are others. If a guidelines page is going to mention them, then they really do need to change when the guidelines change.

Metadata Update from @tibbs:
- Issue assigned to tibbs

5 years ago

Metadata Update from @tibbs:
- Issue close_status updated to: None
- Issue tagged with: committee

5 years ago

Seeing that this is the ticket which has gone the longest without any activity, I thought I would pull this one out for a bit of discussion by the new committee.

To recap, the question is simple: How does the Packaging Committee interface with the various pieces of tooling related to packaging? Should we expect to do the work ourselves to make sure that rpmlint and fedora-review are actually checking things against the guidelines? Should we be directly modifying our rpmdev-newspec packaging to output guidelines-compliant specfiles? What about the various tools which generate specfiles like cpanspec?

We should decide how active a role we want to take in keeping those things up to date. This could range from "not at all", leaving it to the maintainers to keep up with guideline changes all the way to the committee basically acting as maintainers for those packages.

My personal belief is that it would be great if being on FPC basically made you a maintainer of rpmlint and fedora-review and guidelines changes would be expected to be accompanied by updates to the relevant packages. I also know that isn't really feasible. It would still be great if we tried to keep things synchronized.

Metadata Update from @tibbs:
- Issue untagged with: committee
- Issue tagged with: meeting

4 years ago

I think we at least should try to hook the actual maintainers and talk to them, filling bugs if needed. I don't really feel like patching e.g. cpanspec myself.

OK, you might not want to patch the various tools that generate specfiles, but what about rpmlint?
Obviously I know that rpmlint has an independent upstream but Fedora's configuration is maintained within the Fedora packages.

And personally, I'd have no problem patching cpanspec if it needed patching, because I have no problems with Perl.

We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2018-05-24/fpc.2018-05-24-16.00.txt):

  • x657 Keeping packager tooling in sync with our guidelines (geppetto,
  • LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1523826 is perhaps
    a useful example. (tibbs, 16:22:16)
  • Committe doesn't mind doing work ourself, if we have time … which we
    often don't. (geppetto, 16:26:58)
  • ACTION: tibbs In his copious free time will survey how out of sync.
    the tooling is. (geppetto, 16:28:06)

Nothing left to do here.

Metadata Update from @tibbs:
- Issue close_status updated to: nothingtodo
- Issue status updated to: Closed (was: Open)

4 years ago

Login to comment on this ticket.