https://bugzilla.redhat.com/show_bug.cgi?id=2022991 --- Comment #7 from Oleg Girko <ol+redhat@xxxxxxxxxxxxx> --- So, I presume, you want me to make the spec file as readable and simple as possible. I want the same spec file to retain compatibility with different versions of Fedora, as well as CentOS/RHEL, and not break any builds in my OBS. Let's try to find middle ground. I've localised all compatibility workarounds to 3 first lines of the spec file. (In reply to Vitaly Zaitsev from comment #5) > > The reason for making a separate systemd subpackage is to make it optional. Not everybody wants to run i2pd as a system service, some people may prefer to run it as a regular program. > > It's completely useless without systemd modules. Fedora uses systemd as its > unified init system. That's why I think, these units should be moved to the > base package. This is not only about systemd service file, it's also about creating a user and having systemwide configuration files. But anyway, I've made a concession here and merged systemd subpackage into the main package. Unfortunately, this caused systemd service to stop and become disabled during package upgrade because it removes obsolete i2pd-systemd package, and %systemd_preun macro used in %preun script of this removed package disables and stops i2pd service. The service file now belongs to i2pd package and has to be enabled and started again manually. I didn't find a sane way to prevent this from happening. > > I'd like to have a single spec file for both CentOS 7 and Fedora and avoid conditional statements as much as possible. > > %cmake3 macro is obsolete and should not be used. So, to future-proof my spec file against removal of %cmake3 macro, I've added check in the beginning of the spec file, so %cmake3 will be defined as %cmake if this macro is not defined. > Use %cmake for Fedora and %cmake3 for RHEL7. And having different spec files for different distributions (or having different spec files in Fedora infrastructure and in my OBS) is what I strongly oppose against. > > Done using CMAKE_SKIP_RPATH variable instead. There is no %cmake_install in %install section, all files are installed manually, no internal shared libraries used, so no need to build i2pd with rpath pointing to builddir. > > RPATH is strictly forbidden on Fedora. If it exists, it must be removed. This is why I use CMAKE_SKIP_RPATH. This results in RPATH not included in the binary during the build (instead of being removed during install). > > This is needed for migration from older version of this package. Some of users may have older version installed from my OBS repo, and it would be a very unpleasant surprise for them if their configuration was not migrated to the new place automatically. Is there a better, more recommended way to migrate configuration files to a new (more standards conforming) location? > > Such scriptlets are not allowed, because they are touching different files > and directories not owned by your package. If you want to publish your > package to Fedora, it must follow current Fedora packaging guidelines. > > In general such scriplets must be guarded with %triggerrun: > > %triggerun -- %{name} < 1.0.0-2 > ... do some hacks ... OK, I've moved it to %triggerun section. > > There is a changelog, it's just stored in a separate file in OBS > > Fedora doesn't allow detached changelogs (only auto-generated from Git > history). > > > Changelog URL: https://obs.infoserver.lv/package/view_file/i2p/i2pd/i2pd.changes?expand=1 > > Incorrect. You must move contents of this file to %changelog section of the > base SPEC. Please don't worry about this. This is not detached changelog. It's just the way OBS stores spec file and its %changelog section. The spec file used for build (and included into SRPM as a result) has proper %changelog section. And of course, the spec file in the Fedora's Git repo will also have full %changelog once this repo is created. > > It can't. The "build" directory is a special part of i2pd source, not a normal builddir: "CMakeLists.txt" file and cmake modules are located there. The builddir is created inside "build" directory for out of source build. > > Just use %cmake -S build. No, I can't. The %cmake macro in Fedora already uses -S option. Also, changing directory before building looks more readable to my taste. > > This will break build for older Fedora versions (<31) that have no %cmake_build macro. > > We don't have to worry about the EOLed versions of Fedora. Currently > supported are F34, F35 and Rawhide. You should do this. Now I use %cmake3_build. All compatibility workarounds are localised in one place. > > Also please ignore that I didn't increase release number, OBS does this automatically, as you can see from SRPM file name and its version. > > Fedora uses Koji, not OBS. Yes, I know. But since i2pd is still built in my OBS, not in Fedora's Koji, I don't need to increase the release number. I'll definitely will be doing this for builds inside Koji. -- You are receiving this mail because: You are always notified about changes to this product and component You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2022991 _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure