Hello Remi, Thank you very much for your reply! I am a PHP user for years.
I like PHP very much except for breaking compatibility :P
How do you think about adding something similar to the following sentences
to naming scheme of PHP packaging guidelines[1]. I understand the preference
is to update the main package to the latest version, but PHP has its specific
guideline, so I think we should update PHP guidelines. I can submit PR if no
problem.
```
Composer enabled packages (referenced in packagist.org or another registry)
should be named php-vendor-library-%{version}-%{release}.noarch.rpm
However, php-vendor-library%{version}-%{version}-%{release}.noarch.rpm should
be acceptable if php-vendor-library package already exists Fedora’s git
repository and there is no compatibility with it.
```
Currently I am reviewing this ticket. The package name is
php-guzzlehttp-guzzle7.and php-guzzlehttp-guzzle already exists in Fedora’s git
repository.
https://bugzilla.redhat.com/show_bug.cgi?id=1982627
---
1: https://docs.fedoraproject.org/en-US/packaging-guidelines/PHP/#naming-scheme
Regards,
Hirotaka
On Sunday, February 20, 2022, 04:54:51 PM GMT+9, Remi Collet
<fed...@famillecollet.com> wrote:
Le 19/02/2022 à 13:58, Hirotaka Wakabayashi via devel a écrit :
> Hello, I have a question about Fedora Package Naming.
>
> php-guzzlehttp-guzzle's version is 5.3.4, which is already EOL version
> by upstream. The latest version is 7.4.1.
> https://src.fedoraproject.org/rpms/php-guzzlehttp-guzzle
> <https://src.fedoraproject.org/rpms/php-guzzlehttp-guzzle>
> https://github.com/guzzle/guzzle#version-guidance
> <https://github.com/guzzle/guzzle#version-guidance>
>
> In this situation, if I want to package the 7.4.1. version, should the
> package name be php-guzzlehttp-guzzle7? Or should I submit a patch to
> change the php-guzzlehttp-guzzle version? I think php-guzzlehttp-guzzle
> should be upgraded because EOL products potentially contain security
> issues, but most users probably doesn't know the package is EOL or not
> when they install it.
Notice: PHP libraries usually follow semver, so major version means
breaking changes. i.e. v5, v6 and v7 are not compatible.
For guzzle, we have
php-guzzlehttp-guzzle6 version 6.5.5
php-guzzlehttp-guzzle version 5.3.4
php-guzzle-Guzzle version 3.9.3 (retired)
IMHO, we should always use version in name
even if the package name doesn't really matter as we should
always use virtual provides, php-composer(guzzlehttp/guzzle) and range
dependencies.
OK, I know Fedora policy prefers to create "compat" packages
for old versions, but this is a nightmare to maintain as each
update will break everything
if "php-foo" provides a library v1 in /usr/share/php/Foo
a major update will break other packages
creating a compat "php-foo1" in /usr/share/php/Foo1
won't help (other package will have to be fixed)
keeping the compat "php-foo1" in /usr/share/php/Foo
and update the "php-foo" to use /usr/share/php/Foo2
may work, but is really confusing.
BTW I start thinking using system libraries in PHP app
was a interesting adventure, but it also means fightning with
php and composer usage, where everything is bundled in each project.
In the near future a lot of PHP system libraries are going to
be removed from Fedora repository because of fail to build or
fail to install. And there is not enough maintainers to fix them.
(I'm working on building a list I will post on "php-devel" ML)
To be clear nobody uses PHP system libraries directly.
Users needs app (composer, phpMyAdmin, nextcloud, wordpress...)
Developers only use composer to install project dependencies
in the project directory.
As I already said elsewhere, I'm sad, but I'm tired to fight
with PHP projects which don't care of system wide installation
and don't support them, and don't want them, and to fight with
Fedora which don't care of the PHP stack.
Remi
>
> Regards,
> Hirotaka
>
>
> _______________________________________________
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 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/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
