If the php5-* packages start building again, we should check why. They should fail to build as none of the supported openSUSE releases ever had php5.

All the old binaries (e.g. php5-) packages have been removed from our repos. @ecsos, are your problems regarding those packages solved? @adkorte additionally has re-added the "obsoletes" section, but I think we might additionally add the "provides" again.

hmm. I have no time to test till now. But after deletion of php7-Date* packages i use some from my own.

Why are php7 package delete? And what a stupid reason why the package must delete. :-( Don't understand.

Quite simple: it makes no sense to maintain php5-pear-, php7-pear- and (in a year from no) php8-pear-* packages. The actual PHP version used can be determined automatically during packaging.

The main problem here is maintenance. There are loads of packages that are severely out-of-date. By reducing the number of packages the cost (in terms of hours needed by packagers) is reduced.

The fact that you don't understand the reason, doesn't make this 'stupid' (a term I find rather insulting).

Now i have made a little test. The problem is now:

Provides: php-pear-%{pear_name} = %{version} Provides: php-pear(%{pear_name}) = %{version}

Old package not use php-pear-%{pear_name} and not php-pear(%{pear_name}). So, all old package must change this in spec. :-(

Provides:

I think there is a 'not' too many in your comment. I assume you mean old packages use

php-pear-%{pear_name} = %{version}

and the new ones use

php-pear(%{pear_name}) = %{version}

Correct? I don't think this is a problem. The first will be generated automatically, see the following list of Provides from the php-pear-Date package for example:

php-pear(Date) = 1.5.0a4

php-pear-Date = 1.5.0a4-1.1

php5-pear-Date = 1.5.0a4

php7-pear-Date = 1.5.0a4

Yes your right. But the first is no more generate in all packages automatically.

See php7-pear-Mail_Mime Only Provides: php-pear(%{pear_name}) = %{version}

That is because it need to be migrated to be PHP version agnostic.

The notation php-pear(%{pear_name}) = %{version} is the only correct way to reference dependencies for packages. You should not count on that php-pear-%{pear_name} = %{version} is provided, although it currently is through the package name. The former notation has been the recommended way to reference dependencies, it is time to deprecate the one through the packagename.

"php-pear-%{pear_name} = %{version}" is now provided via the packagename; therefore there is no need to specify that within the package.

The main reason for all those changes is, that next year we would have to create all those packages with a "php8-" prefix, and adapt all dependent packages again... The new way gives us time to migrate and test all the packages and to get the into factory. A great advantage fro us maintainers is, that there is that we no longer need to maintain several versions of the same package.

Keep them. Other does not work today!

Deleting php5 packages does not solve this issue.

By why are php5-pear packages still being built (and published) for openSUSE:Tumbleweed? This makes no sense at all. Same for Leap_15.{0,1,2,}. Unless php5 is pulled in from somewhere else, these packages should no longer build, let alone being published.

The reason is just that nobody turned off building. I have done that for many failing projects some time ago but I did not yet do it for all projects.

I still don't understand. In openSUSE:Tumbleweed nothing provides php5 and php5-pear. So how can these packages still be build?

The base PHP package must change the path, then all built projects would automatically be moved to that path. Maybe it's a good time to do this change before the next Leap release. I would very much like this approach. i don't see any real disadvantage because having different PHP versions available at the same time (which would be possible using FPM instead of an Apache module) is not really supported in openSUSE.

Starting with PHP-7.4.0, the installation directory of PEAR is provided by the php7-pear package, which was split-off from the base PHP package (PHP has deprecated built-in PEAR in 7.4 and will remove the option with 8.0). To be prepared, we moved php7-pear to a separate package. The php7-pear package is already in openSUSE:Factory and will replace the php7-pear subpackage once base PHP is also upgraded to 7.4.0.

I have to think of an upgrade strategy for existing installation (which possibly also have PEAR modules not from openSUSE), but I think it should be doable to make this change.

This sounds great! I wanted to work on this splitting (and also splitting off some pear packages (tar?) which were included into php up to now).

If we proceed to unify packages the new "php7-pear" package should be renamed to "php-pear" and obsoletes/provide "php7-pear = %{version}"

So we should start migrating the php[57]- packages to be php-* packages and add the according obsoletes/provides sections for the updating process. As long as the paths defined within pear are used for packaging we can use those packages for current/older distributions as well as for the upcoming ones, having the unified locations. Those definitions should work: ... Provides: php-pear(%{pear_name}) = %{version} BuildRequires: php-pear Requires: php-pear Obsoletes: php5-pear-%{pear_name} Obsoletes: php7-pear-%{pear_name}

for simplification of the update process

Provides: php5-pear-%{pear_name} = %{version} Provides: php7-pear-%{pear_name} = %{version} ... Admins should not forget, that configurations must possibly be adapted to make the new configs working.

Sorry for the formatting, that wasn't intended. lets re-try: ``` BuildRequires: php-pear Requires: php-pear Provides: php-pear(%{pear_name}) = %{version} Obsoletes: php5-pear-%{pear_name} Obsoletes: php7-pear-%{pear_name}

for simplification of the update process

Provides: php5-pear-%{pear_name} = %{version} Provides: php7-pear-%{pear_name} = %{version}

Stupid markdown... :-)

For PHP-7.4.0, the migration of using %{pear_phpdir} to %{pear_metadir} is in progress. I don't want to interfere with that anymore. But for PHP-8, we'll have to do something anyway, so I think it make sense to try to do the migration from php{5,7}-pear to php-pear before the release of PHP-8. That leaves us about a year to fix things.

Thanks for adding the obsoletes section again. I have accepted the package (and - for today) accepted the deletion of the broken packages you have identified.

Indeed. I'm not entirely sure if it is enough to just put in an

Obsoletes: php5-pear-packagename Obsoletes: php7-pear-packagename

is enough for a smooth transition to php-pear-packagename. Don't we need a Provides: php{5,7}-pear-packagename as well to prevent questions during updates?

Of course the Obsoletes should be on two different lines. The markdown interpreter seems to be slightly broken here.

I have had both lines before, but I can't remember if it was only not for having the rpmlint messages or if it was better for updating.

According to https://en.opensuse.org/openSUSE:Upgrade_dependencies_explanation we need both when renaming a package.

You can't link separate packages from another repository and expect things to keep on working. You should either add the other repository as a source in your repository or copy the packages. Repositories as a whole should maintain a consistent state, but this can never be guaranteed for links to individual packages. This is fragile.

Most likely there are branched packages from server:php:applications in the server:Kolab:Extras repository (and the other repositories that are now broken because packages were renamed). Although branching will freeze the version of a package, it still keeps a link back to the origin package. This is fragile as you found out.

If you look at the packages that are now broken because the origin was removed, you´ll see that the sources are still there. I you branch a package to another repository, it is better to sever the link back to the origin through

osc detachbranch

We must delete the php{5,7}-pear packages from server:php:applications in order to reduce the maintenance burden and to prevent people from using obsoleted packages.

I fully understand your frustration this has caused you, but this must be done before PHP-8 is released and we would have to add hundreds of new php8-pear packages. This use of PHP versions in PEAR packages doesn't scale with the resources available.

Roundcubemail should be working again after the request I submitted yesterday for PHP independent versions of the packages are accepted.

It breaks because roundcubemail still uses the deprecated php-pear-Package_Name notation for the dependencies instead of php-pear(Package_Name) and the first is not provided (yet).

@Ecsos, don't give up! It's very important to get your responses as we all want to have a fully operating PHP ecosystem for openSUSE!

You might remember, that after releasing PHP7 with - I think openSUSE 42.2 - we had huge problems as e.g. roundcubemail couldn't be installed on the release(!) version for a while and users had to dig around with a mixture of PHP5 and PHP7 libraries symlinked together (you can still find the issues in bugzilla).

This time we try to handle that issues earlier and - hopefully - have all of them been solved in the next days. Please keep testing, improving and give your feedback!

Yes i can remember. But why must delete a package complete before? Why not only change the spec? Or should all packages renamed to php-pear-* (also without 5 or 7) ?

PS: roundcubemail > 1.3.* is not compatible to old kolab 3.4

The reason for deleting/recreating the package is because we can't get packages in factory and in releases when the name of the package, the spec- and -changes files as well as the resulting package do not match. It's a lot of work to synchronize that @adkorte has written a script which allows him to speed up the process, but it's still a lot of manual work, especially when packages do not package as expected. I hope this is the last time we have to do that in this way, we save resources (in longer term) and especially because the PHP developers speed up developing newer versions.

Okay. Does i understand it right? In future with php8 i can only install php8 and applications which support php8? And when an application need php7 i cannot install it?

You could then use a repository for an older distribution providing PHP7. No matter which PHP version we have, we install the exactly same files in different locations. We'd like to avoid that in the future.

I think i have unclear expressed myself. As example. When php8 is standard in Leap 15.x, can i than only use applications which support php8?

I don't think both PHP versions will be provided but it could happen. IMHO the changes between PHP versions are not that large like from 5 to 7 and the frequent changes forces developers to stay up-to-date with nowadays.

You also should change pear-Archive_Tar in php7 package itself.

Where do you see that?

After change require in an package from me.

See in php7 spec file from Leap 15.1 update repo.

For releases that package will not be renamed, but in the current php7 development project the naming has been improved.

We're going to provide a replacement php7-pear which will be kept up-to-date with the latest versions. It was a grievous mistake to require this in the php7-pear package and bundle php7-pear(Archive_Tar) in a separate package. It rather should have stayed in the php7-pear package and with a couple of

Provides: php7-pear-Archive_Tar = 1.4.0

Obsoletes: php7-pear-Archive_Tar < 1.4.0

and a couple of more like that.

Worse, it is even incomplete, as the PEAR, Console_Getopt, Structures_Graph and XML_Util are not provided. So packages may want to install them, while in fact they already are.

I have added a delete-request #984487 for all the horde packages.

And why? Imho it's alive.

You are right, it's really alive. But nevertheless, there are no longer pear-packages available and the packages here are php5 compatible and do not at all work with php7. I leave the decision to the maintainers, but I think those packages should be removed as they can no longer be built and are no longer maintained since some years in server:php:applications