Completely corrected the previous comments.

I want to make php.ini supplied only as part of cli, and other SAPIs supplied with a symlink to ../cli/php.ini, and each SAPI would require php-cli. This seems convenient and logical to me, since php-cli is needed in any SAPI (e.g. to run cron tasks), but I don't know how this would affect multibuild and would you approve?

Regarding apache, I haven't used it in about 10 years and I only see it in projects more than 10 years old. But apache is usually used with php-fastcgi SAPI, it is specially designed for it, and php-fpm with more complex configuration for performance is used with asynchronous web servers. Seeing apache+php-fpm configuration is wild to me, it's like integrating a diesel engine into a steam locomotive.

I understand this site https://build.opensuse.org as well as all other openSUSE sites are still using apache in this configuration. This is most likely due to complex user authentication and unwillingness to switch to the more flexible and efficient nginx+lua_module+redis+php-fpm bundle.

Experienced users can easily write any config, default settings are aimed at inexperienced beginners. They, installing ego for the first time, will use it this way, which seems wrong to me, but I don't have a complete picture of why this is so and whether it can be fixed.

There should be no {} brackets around the macro calls %apache_restart_if_needed. These were probably added by spec_cleaner in error.

Don't edit older entries in the changelog. This is frowned upon as it is changing history. Entries more than about three years old are purged from the changelog anyway, so the 2017 entries will not be distributed anyway.

Please drop the 'fdupes' call. It doesn't harm to include these three files as is (only 35 bytes each), you're saving next to nothing here.

What is your rationale for adding the '-p' (preserve timestamps) to the 'install' lines? The timestamps will be set by the buildservice to the source timestamp regardless, whatever the timestamp on the files in the buildroot is, is totally irrelevant. I also don´t understand the change to use 4 digit '-m' flags if the first digit is 0. They won't be treated any differently.

Last, adding the keyring as a source is wrong. It is OK to add it as a comment (to show where it is downloaded from) but you don't want to automatically download it. If somehow upstream is compromised and the keyring is replaced as well, you've removed our last line of defence against using tampered sources. Changing the keyring must always be a consious decision by a packager after verifying that the new keyring is valid/genuine. It should never be replaced automatically (which happens if you add it as a URL source). As to the changing of the upstream source, I'll leave this to @pgajdos to decide if this has merit.

Илья Индиго (13ilya) - 3 months ago

author

1 Fixed in the last SR.

2 I'm not editing the content, but the headers. My email has changed and I've updated my contact information. I don't see anything wrong with that. Some developers add their copyright, which I don't do, because I consider an up-to-date email in the changelog sufficient, provided it is up-to-date.

3 Please explain what is wrong with using fdupes? Even if it doesn't save much space, it eliminates the rpmlint warning Requiring this package when building does not result in requiring this package when installing the built package. But even if it did, the mandatory ruby-common package requires it and the user already has it installed.

4.1 When the -p flag is used, the installed file is passed the original file creation time, instead of having that time set by the build system each time. This way the user can see the real time of file creation, which is convenient.

4.2 4 digits ensure that special flags are reset if they are suddenly set. 3 digits do not!

5 I found and scrutinized the documentation for the source code validation mechanism. https://en.opensuse.org/openSUSE:Package_source_verification Despite the fact that the example does not use the url for the keyring file, there is no warning that it should not be done! I also reproduced this validation mechanism and added it to the %check section nginx package and experimented by leaving the url for the correct file, but uploading the wrong keyring file. The test failed, the original file was not replaced by the uploaded one. Later, when the nginx package is accepted by Factory, I will run this experiment on Factory auto-checker.

---

Arjen de Korte (adkorte) - 3 months ago

target maintainer

2 I will not sign off changes to old changelog entries. The changes you made, are not visible in the rpm -q --changelog php8 (see for yourself) and therefor deemed not beneficial. This is not up to debate.

3 Using 'fdupes' is not without drawbacks. There is essentially no benefit to merge them into one given the small size. This is not up to debate either.

4.1 The openSUSE buildservice doesn't work that way. I already explained that the timestamps of the files/directory in the buildroot are irrelevant (these are set later on by the buildservice). Adding this flag makes no difference at all and therefor is without merit.

4.2 Same as 4.1.

5 I already explained why this shouldn't be done.