[Bug 2022991] Review Request: i2pd - I2P router written in C++

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite Conditions]     [KDE Users]

  Powered by Linux