#153 Add simpler Banner package to packaging tutorial
Merged by oturpe. Opened by oturpe.
fedora-docs/ oturpe/package-maintainer-docs tutorial-banner  into  main

Download 153.patch

Packaging tutorial's approach of packaging GNU Hello has suffered from certain complexities in GNU Hello package. The package is quite old and uses some tooling from the GNU project that are not very widely used any more, such as Texinfo. Also, the package is old and thus suffers from e.g. having a file that is not UTF-8 encoded. To avoid immediately exposing tutorial readers to these quirks, make GNU Hello part 2 of the tutorial and add a simpler package, Banner, as part 1. This way the reader can reach a complete specfile, compliant with Fedora guidelines, quicker, and still get a feeling for resolving packaging quirks in the second part.

In the future, basing the first tutorial on real packages should probably be switched to hosting dedicated "test project", which avoids any quirks and can be packaged to Fedora requirements using only Fedora's set of RPM macros. Such package should also avoid GNU Autotools and be based on CMake or Meson, which are simpler to understand and more widespread today.

rebased onto 3f667537f4e1495c60dea938ea790274e2f71ab9

rebased onto e6e4c773c5d19ab92f39774a947ed8d8d6f6b3b2

  • In particular, https://docs.pagure.org/fedora-infra.rpmautospec/[rpmautospec] is unlikely to be available.

I don't think that's true. rpmautospec has been ported fairly widely…

  • For banner, package can simply be named banner.

can → should (since we're just applying the rules, and the result is "banner").

I read through the whole text, and +1 from my side. I think it's nice and clear and a better first example.

You will see that the only dependency of GNU Hello is glibc,

Should say banner instead of GNU Hello.

I don't think that's true. rpmautospec has been ported fairly widely…

That part about rpmautospec not being available in CentOS etc. was just copied from the previous tutorial. You are probably correct that the statement is misleading today. I will replace the paragraph with something like "this tutorial may or may not work in downstream distributions".

can → should (since we're just applying the rules, and the result is "banner").

I will apply this suggestion as well.

rebased onto c3480132757214968c0d047934602aca1a22df68

rebased onto e9c53785442355c6fbed11c8aaedf12953090269

I applied the requested changes merging now.

Pull-Request has been merged by oturpe

Metadata