Use help2man to generate a man page

[lukash]

Adds a .spec file copied from Fedora downstream and then adds help2man man page generation to it. A minor change was needed to the --help output so that help2man formats it correctly for the man page. The man page looks like this:

MICRODNF(8)                                                                                      System Administration Utilities                                                                                     MICRODNF(8)

NAME
       microdnf - Micro DNF

DESCRIPTION
   Usage:
              microdnf [OPTION?] COMMAND

   Commands:
       clean  Remove cached data

       install
              Install packages

       remove Remove packages

       update Update packages

   Help Options:
       -h, --help
              Show help options

   Application Options:
       --disablerepo=ID
              Disable repository by an id

       --enablerepo=ID
              Enable repository by an id

       --nodocs
              Install packages without docs

       --setopt=FLAG
              Set transaction flag, like tsflags=nodocs

microdnf 3.0.1                                                                                            February 2019                                                                                              MICRODNF(8)

[Conan-Kudo]

Why do we want a spec file in here?

[lukash]

Why do we want a spec file in here?

@j-mracek care to provide a more coherent explanation than I'd be able to? :)

[j-mracek]

The spec in upstream was my idea. It should provide a better way how to easily synchronize changes in spec with various distros rhel/centos/fedora. Additionally we can keep track of changes in spec (conflict, requirements, and so on) in upstream. We have to keep in mind that when upstream patch requires changes in spec, the patch is often introduce by one developer, then often the release is not performed by the same person, therefore some problems could happen (also it clearly declare who is responsible for what). Additionally nearly all project in rpmsoftwaremanagement have a spec in upstream, and as you know I like uniformity. From my experience, it is really good idea.

[Conan-Kudo]

@j-mracek I'm okay with this, just not in this PR.

[lukash]

@Conan-Kudo What's the problem with adding the .spec file in relation to this PR? Clearly I need to add the .spec file to be able to add the man page generation to it.

[Conan-Kudo]

@lukash man page generation should be added to the build scripts. It should not require the spec file to do so. Plug it into Meson and CMake.

[lukash]

@Conan-Kudo oh well. I agree and it was my initial intention, but @dmach convinced me to do it this way...

[lukash]

@Conan-Kudo also, to kind of present the argument (and not just blame @dmach 😃), there are two build systems which are both quite basic, they are not aware of the package version (which is tagged in git) and help2man requires the version to be ideally accessible through microdnf --version or passed via an argument.

At the same time microdnf is a temporary solution for (AFAIK mostly RHEL?) containers, so the .spec file approach is easier and sufficient for the temporary package.

[Conan-Kudo]

@lukash actually, both build scripts are supposed to be aware of the version and set it in the source code. Nobody is updating it in the meson.build file or setting it in the CMakeLists.txt file.

[lukash]

@Conan-Kudo there is nothing like that in place AFAICS. Meson has the version specified as '1' and no version is mentioned in cmake. There is no code to pass the version define to the code and no code to make use of it.

[Conan-Kudo]

Meson is not currently configured to pass the project version into the sources, as it can be: http://mesonbuild.com/Configuration.html & http://mesonbuild.com/Reference-manual.html#project

CMake can have the project version set and pushed into the code too, though I don't have the reference off the top...

[lukash]

I know it can be done (and it's not rocket science), just saying it's not there. And there are two build systems. Duplicating the version in three places (git tag, meson, cmake) is not really a great way forward. AFAIK most projects that tag the version in git pull it into the build system from there, so that's what I would do if I wanted to do it correctly (although then you may have problems building from sources that aren't git, so it's probably a bit more complex and I'm perhaps not entirely aware of all the details).

[Conan-Kudo]

Meh, we should drop the CMake build scripts again. Nobody uses them outside of RHEL, and now RHEL has Meson as an available build dependency...

[j-mracek]

@Conan-Kudo I reverted drop of CMake build because of RHEL7 where Meson was not present.

[Conan-Kudo]

@j-mracek Meson is definitely present in the RHEL 7 build root, because libmodulemd was not buildable without it, and it's available in RHEL 7.

[j-mracek]

But not at time of revert! And got an angry when we lost a possibility to release updates to RHEL7.

…

On Thu, Feb 28, 2019 at 12:39 PM Neal Gompa (ニール・ゴンパ) < ***@***.***> wrote: @j-mracek <https://github.com/j-mracek> Meson is definitely present in the RHEL 7 build root, because libmodulemd was not buildable without it, and it's available in RHEL 7. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#40 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMJbF-ZzbCp0VVNDsqJ-fyeLrZR9LtU1ks5vR7_0gaJpZM4bHVRK> .

[Conan-Kudo]

@j-mracek I see. Well, we can drop them again. :)

[j-mracek]

I prefer an unified style and we have not enough time to port everything to Meson (different priority). I am sorry.

[lukash]

@j-mracek actually, I'd like to appeal for using meson here. It is considered a superior build system (I admit I might be biased against cmake 😄 ) and I don't think "consistency", as in having the same build system across all components is a good argument. With that argument we could not move to new technologies with anything, because we will never be able to switch on all the components simultaneously.

IMHO gradual improvement is much more important than consistency. If our stance is such that we consider meson the better build system and would prefer it (without regard to the amount of work needed for the change), lets keep meson here and opportunities may present themselves in the future to move to meson on other components (community contributions, radical changes that warrant the switch due to having to make big changes to the build system anyway, etc.).

The question remains whether to do the help2man in .spec or in the build system. I've actually got the meson code to do it in a branch and it seems the version is not pulled from git tags on SM projects anyway, it is duplicated in the build system files, so it will be trivial to set it in meson too.

[lukash]

@Conan-Kudo so basically we want to decide which build system (CMake vs Meson) we prefer in general. If there are sufficient reasons for us to prefer Meson over CMake, we can stick with Meson here and in the future also prefer to move to Meson with our other components. We do not have any strong opinions right now and no technical justification. Would you be able to provide some justification for preferring Meson as our build system?

[Conan-Kudo]

@lukash For this program in particular, Meson is easier to work with since working with GLib, GTK+, and pkgconfig is easier.

But the other thing is that building the DNF stack in some platforms is a bit more difficult in CMake.

I think that Meson would be easier for some targets... @midipix, could you comment on this?

[j-mracek]

We have to also considered that we have a huge plans with microdnf that includes functional parity with dnf/dnf-plugins. The new code will use the new C++ API.

[ignatenkobrain]

It is pretty funny to see this, because microdnf started as "tiny replacement for dnf in containers" :)

[lukash]

Well the new thing (which according to plans is also going to be called microdnf, just saying in an attempt to alleviate the confusion) will have little in common with the current microdnf code and AFAIU the current microdnf code will have to stay around probably for the lifetime of RHEL8, right? So there's really no direct tie between the two. Though we should consider meson for such an application as the microdnf successor and really settle on either meson or cmake.

But the other thing is that building the DNF stack in some platforms is a bit more difficult in CMake.

I think that Meson would be easier for some targets... @midipix, could you comment on this?

@Conan-Kudo I'm suprised to see this, from what I understood cmake is much more mature than meson and from what I've heard has good multiplatform support, whereas meson being much younger still might have some kinks to iron out... Outdated information? Do you think meson is actually better in this regard?

As for being easier to work with (and the language being more user-friendly), it's a significant advantage for me personally, but I think people that know and are comfortable with cmake might not be so high on this 😄. Do we have anything else?

[j-mracek]

@please what's the status?

[lukash]

@j-mracek basically what you see here, nothing else happened.

We don't have any substantial arguments either way. I'm personally in favor of meson, just because the language is more modern, streamlined and in general nicer, but I can see other people on the project preferring cmake because of familiarity.

I recall doing a search but didn't find anything significant for a comparison really.

Not sure how we proceed from here.

[j-mracek]

@lukash Is the patch ready for both build systems?

[lukash]

Nope. I've got a patch for meson lying somewhere that I wrote originally before switching to the soboptimal .spec solution.

We should keep only one of the build systems in any case...

[lukash]

We are unable to resolve the build system conflict right now. We might go with meson in the future, but at this moment we can't drop cmake.

I've pushed patches that add generation of the man page to both build systems and dropped the spec file.