PHP libraries and applications

This project is the development project vor various PHP libraries and applications.

Name Changed
Comments 87

Eric Schirra's avatar

Some pear packes produce errors since last update and cannot install in Leap 15.1

File /usr/share/php7/PEAR/Mail/mime.php from install of php5-pear-Mail_Mime-1.10.0-lp151.1.1.noarch (OBS - server:php:applications) conflicts with file from install of php7-pear-Mail_Mime-1.10.4-lp151.13.1.noarch (OBS - MyRepo)

File /usr/share/php7/PEAR/Mail/mimePart.php from install of php5-pear-Mail_Mime-1.10.0-lp151.1.1.noarch (OBS - server:php:applications) conflicts with file from install of php7-pear-Mail_Mime-1.10.4-lp151.13.1.noarch (OBS - MyRepo)

File /usr/share/php7/PEAR/Net/IDNA2.php from install of php7-pear-Net_IDNA2-0.2.0-lp151.9.1.noarch (OBS - MyRepo) conflicts with file from install of php5-pear-Net_IDNA2-0.1.1-lp151.9.1.noarch (OBS - server:php:applications)

File /usr/share/php7/PEAR/Net/SMTP.php from install of php7-pear-Net_SMTP-1.8.1-lp151.11.1.noarch (OBS - MyRepo) conflicts with file from install of php5-pear-Net_SMTP-1.7.1-lp151.14.1.noarch (OBS - server:php:applications)

File /var/lib/pear/Mail_Mime.xml from install of php5-pear-Mail_Mime-1.10.0-lp151.1.1.noarch (OBS - server:php:applications) conflicts with file from install of php7-pear-Mail_Mime-1.10.4-lp151.13.1.noarch (OBS - MyRepo)

File /var/lib/pear/Net_IDNA2.xml from install of php7-pear-Net_IDNA2-0.2.0-lp151.9.1.noarch (OBS - MyRepo) conflicts with file from install of php5-pear-Net_IDNA2-0.1.1-lp151.9.1.noarch (OBS - server:php:applications)

File /var/lib/pear/Net_LDAP2.xml from install of php5-pear-Net_LDAP2-2.2.0-lp151.3.1.noarch (OBS - server:php:applications) conflicts with file from install of php7-pear-Net_LDAP2-2.2.0-lp151.9.1.noarch (OBS - MyRepo)

File /var/lib/pear/Net_SMTP.xml from install of php7-pear-Net_SMTP-1.8.1-lp151.11.1.noarch (OBS - MyRepo conflicts with file from install of php5-pear-Net_SMTP-1.7.1-lp151.14.1.noarch (OBS - server:php:applications)

MyRepo are links/branches to server:php:applications

Why should i install php5?


Arjen de Korte's avatar

The conflicts are all for php5 packages that no longer build (the version numbers of are not the same). It looks like somebody forgot to clean the repository. Leap_15.1 never had php5, so these must be remains from an earlier build in Factory.

You have to explicitly delete the build RPMs from the repository before disabling a package. Otherwise the packages will still be considered in checking which version should be installed.

I think the best thing to do is to clean out all RPMs for all buildtargets and start fresh again without all this stale cruft. The php5 packages will then fail to build for virtually all recent distributions, but that is OK since they will not be installable anyway.

It has nothing to do with the removal of the Obsoletes in the packages.


Johannes Weberhofer's avatar

@adkorte, I think you are right, I did a "osc wipebinaries" on the projects, let's see if old things disappears.


Arjen de Korte's avatar

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.


Johannes Weberhofer's avatar

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.


Eric Schirra's avatar

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.


Arjen de Korte's avatar

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).


Eric Schirra's avatar

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:


Arjen de Korte's avatar

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


Eric Schirra's avatar

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}


Arjen de Korte's avatar

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


Arjen de Korte's avatar

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.


Johannes Weberhofer's avatar

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


Johannes Weberhofer's avatar

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.


Arjen de Korte's avatar

That is because there are still packages for php5 in this repository. I should have filed delete requests before submitting packages that no longer obsolete php5 variants.


Eric Schirra's avatar

Why not leave obsolet tag in spec?


Arjen de Korte's avatar

PHP5 reached EOL on January 1st 2019, there is no point in maintaining packages for it


Eric Schirra's avatar

Than deleted php5 Packages. In time Packages can Not Update or install. The Packages would install ist PHP Version, too.


Johannes Weberhofer's avatar

@adkorte, @ecsos I was aware of the changes introduced by removing the Obsoletes/Provides section when I have accepted yesterdays changes. After reading @ecsos comments I think we should really add this section again!

The main issue why I have introduced those two lines was not to maintain php5 packages, but to simplify the update processes for admins. There were many issues when opensuse switched from php5 to php7.

Opensuse is not packaged in a way, that php5 and php7 installations of packages can really exist simultaneously, several issues (as the shared /var/lib/pear) file must be cleared to allow that. IMHO the same issues will arise when PHP8 is about to be released next year.

I think for now we should re-introduce the Obsoletes/Provides section in all php7 pear-packages to keep upgrading and maintaining simple. @adkorte, can you do that or shall I add the lines?


Arjen de Korte's avatar

I think it is insane to add Obsoletes for a php version that has been out of extended support for 11 months already. Just deleting the php5 packages should be sufficient, as they can't be build in any of the supported versions. I filed a couple of delete requests, also for php5 packages that are linked from Factory (why?) and obviously are no longer available.

When PHP8 is released, we'll have to add the obsoletes again (I'm aware of that) but this will require migrating all packages anyway, so that would be a good time to do it.

What concerns me most is that there seems to be insufficient manpower to keep server:php:applications in a healthy state. When I upgraded the packages that are in openSUSE:Factory, I already noticed that 2 out of 10 packages had version updates upstream that went unnoticed (for years in one case). In order to keep this repository relevant, it should follow upstream. For the record, I don't use any php7-pear-* package from either openSUSE:Factory or server:php:applications because of this.

I only filed these request because these packages will no longer build in openSUSE:Factory in a couple of days due of the wrong use of the %{pear_phpdir} when ignoring channelinfo during builds. Since PEAR 1.10.0 (somewhere back in 2012), the channelinfo goes into %{pear_metadir} with a fallback to %{pear_phpdir}. In PHP-7.4.0 (which is about to be released in openSUSE:Factory) the metadata will go in /var/lib/pear instead of /usr/share/php7/PEAR/.


Johannes Weberhofer's avatar

@adkorte, the obsoletes section is only to allow automatic updates. They don't hurt anyone therefore I'd like to keep them (and replace them to php7 obsoletes when switching to php8). I'm possibly a little more conservative as you regarding the updated processes. It's just nice to update old systems without any need to fiddle around with uninstalling packages manually.

You are totally right, there are many out of date packages for this repo, there seem to be not enough manpower to do so; in the meantime I'm also using pear-packages very seldom for the same reason.

However, thanks for all you input!


Eric Schirra's avatar

Keep them. Other does not work today!


Johannes Weberhofer's avatar

Deleting php5 packages does not solve this issue.


Arjen de Korte's avatar

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.


Johannes Weberhofer's avatar

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.


Arjen de Korte's avatar

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


Johannes Weberhofer's avatar

Question regarding php5 pear packages and php-application packages: Is it already time to drop the packages? I know, there are still many systems around serving PHP5 based applications, but at the same time I think nobody is still maintaining the packages.

A huge number of horde packages were maintained by @ralflangb1, but those seem to be unmaintained today. Shall those be deleted? Is there somebody who want to port/maintain the packages for the future?

Please let us know your opinion before php5 packages are going to be removed. We should also keep in mind, that SLE still supports PHP5.


Arjen de Korte's avatar

I would only remove php5 packages when a suitable php7 package is available. My 'pearify' script can use the old specfiles as a kickstarter to create new specfiles for php7 like packages. There are for instance a couple of php5-pear-Date_Holidays_* files that still need converting to php7. It's a whole lot easier if I have a starting point.

Regarding the use of PEAR packages in SLE, I think this is impossible to maintain for us. This would require to also keep older versions just for php5 versions and (see above) I don't think we have the manpower to do so. For people that really want to run PHP5, there is still the possibility to run the 'pear' command and install the packages from 'pear.php.net' directly.

I for certain am not going to invest time in supporting older releases of SLE that use packages that are no longer maintained in an openSUSE release.


Johannes Weberhofer's avatar

This script sounds very interesting. I always thought for writing one but as I never had enough time to do so. I also don't invest time to maintain those old packages.


Johannes Weberhofer's avatar

@ralflangb1 says he's still maintaining those packages for usage in SLE and containers. I don't know, if the packages should be removed. For Leap and Factory all those PHP5 packages are unuseable.


Arjen de Korte's avatar

Indeed. I don't know why these packages are still being built (and how?), but at the very least we should not publish them. Looking in the repositories for openSUSE:{Leap_15.0,Leap_15.1,Leap_15.2,Tumbleweed}, I see all have many php5-pear packages that really shouldn't be there as there is no way these are installable.


Eric Schirra's avatar

I use no php5 packages since serveral month. I use only php7. And for packages i'm maintainer i update this packages if necessary. But the real point is, that the packages must installable or updateable today. Not relevant what is tomorrow.

And what ist when PHP8 is out and obsoletes is missing for php8? The same procedure and problem with php5.


Arjen de Korte's avatar

True. A way to solve this, if we somehow manage to strip out the PHP version from the packaging. The PEAR packages themselves are identical, so a php-pear-XML_Serializer should be installable on PHP 5, 7 and 8 without a need for any changes. The problem is, we package them in /usr/share/php{5,7,8}/PEAR/, so we make them different. Isn't there some way to do away with that?


Johannes Weberhofer's avatar

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.


Arjen de Korte's avatar

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.


Johannes Weberhofer's avatar

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.


Johannes Weberhofer's avatar

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}


Arjen de Korte's avatar

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.


Johannes Weberhofer's avatar

SLE_11 had it's support end in March 2019. I think we should remove it from the project. Any objections?


Arjen de Korte's avatar

I'm all for removing old cruft. We even have some php5-pear packages in the openSUSE:Tumbleweed repository, we should really clean that up also, because there is no way that you can ever install this. I think we really shouldn't make these available, they shouldn't have been build in the first place.


Johannes Weberhofer's avatar

@ralflangb1 asks for a composer packaging strategy. Unfortunately we don't have such a strategy and I don't know if it's really possible to have that. The largest problem is, that (IMHO) composer does not support to have several versions of a package on the system. So we should constantly have conflicts between the packages. Any idea how we should handle this?


Eric Schirra's avatar

Insert Obsoletes again. This work for many, many years.


Arjen de Korte's avatar

This has nothing to do with obsoletes.


Johannes Weberhofer's avatar

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.


Johannes Weberhofer's avatar

I have updated the documentation at https://en.opensuse.org/openSUSE:Packaging_PHP to reflect the unification of packages for different php version. Please review and adapt!


Arjen de Korte's avatar

I would omit the following part:

Warning: With PHP 8 it is planned to move the /usr/share/php7/PEAR locations to /usr/share/php/PEAR

This is too soon in my opinion and not necessary either. There is actually no reason to do this, as during packaging the location is determined from the %{pear_*} macros, which can be different between PHP versions. Provided packages strictly adhere to using these macros, it should be irrelevant what the actual location is as the php{5,7,8}-pear (sub)package will set what is appropriate. This is available now already.

What really should be stressed, is to strictly adhere to the use of the macros and not override these settings on the 'install' line. So although %{pear_docdir} is usually the same as %{pear_phpdir}/doc, only the first must be used and the second not. Since PEAR 1.10.0 the metadata will can be installed in a different location so use the %{pear_metadir} macro instead of %{pear_phpdir} or %{php_peardir} for ignoring the channelinfo files. Starting with PHP-7.4.0 this data will be moved to %{pear_metadir} to adhere to the FHS.

In all likelihood, we will have a php8-pear package when PHP-8 is released and not a php-pear package. PEAR and PECL are currently bundled and not easily separated. So while we might create PHP version agnostig PEAR packages, this probably won't be the case for PECL. As the maintainer of the php7-pear package (and most likely for the php8-pear package as well) I will make sure that the appropriate Provides/Obsoletes are in place, so that packages only need to (Build)Require the capability 'php-pear'.


Johannes Weberhofer's avatar

The php[57]-pear packages already provides "provide php-pear = %{version}", this allows us to create php-version neutral packages for the libraries. OBS will then decide which php/pear package in the distribution will be used and where the files are installed to. There is no need for packager to know those details.


Arjen de Korte's avatar

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?


Arjen de Korte's avatar

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


Johannes Weberhofer's avatar

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.



Eric Schirra's avatar

I think all php application wich use pear packages are now broken.

Example: server:Kolab:Extras roundcubemail

Requires

Symbol Provided by

php-pear-Auth_SASL >= 1.0.6 php7-pear-Auth_SASL php-pear-MDB2_Driver_mysqli
php-pear-Mail_Mime >= 1.9.0
php-pear-Net_IDNA2 >= 0.1.1
php-pear-Net_LDAP2
php-pear-Net_SMTP
php-pear-Net_Sieve >= 1.3.2
php-pear-Net_Socket
php-session php7-fpm apache2-mod_php7 php7-fastcgi php7


Arjen de Korte's avatar

Nope.

Whoever maintains server:Kolab:Extras isn't providing his/her users a servers by linking packages to server:php:applications and then make changes to the packages. Whenever something changes in the origin package in server:php:applications, this very well could break the linked package in server:Kolab:Extras. This is really bad use of OBS. If one needs a newer version of a package, submit a SR to the origin package or do a copypac to your repository and make the changes there. This is the case for php7-pear-Auth_SASL.

The php7-pear-HTTP_Request2 and php7-pear-Net_URL2 are indeed broken now. The first basically everywhere because the unit tests fail, the second because some repositories no longer provide php-phpunit which is needed for unit testing.

Please verify why things break. Neither of these things has to do with changes in server:php:applications, the root causes are outside of this repository.


Eric Schirra's avatar

roundcubemail will not install anymore. Probably applies to all other php packages too. But I give it up. All arguments are beaten in the wind. Packages are not built anymore ... Packages can not be installed ... But everything is fine. Great. PS: The php packages are made in my repo without error.


Arjen de Korte's avatar

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.


Arjen de Korte's avatar

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.


Arjen de Korte's avatar

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).


Johannes Weberhofer's avatar

@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!


Eric Schirra's avatar

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


Johannes Weberhofer's avatar

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.


Johannes Weberhofer's avatar

I have now * disabled the php7-pear packages which we already provide php-pear for * Set Prefers for the packages, so that the dependent packages can be built again * In all projects that link to php7- packages we already provide version agnostic package for, please replace the links! If everything works nicely I'll make an announcement on the mailinglist and I try to replace the packages in factory.

Please test and comment :-)


Eric Schirra's avatar

Should i now replace all php7-pear-* with php-pear in my application packages?

When yes, how do i tell the package it should only use php7 and, at example, not use php8?


Johannes Weberhofer's avatar

I'd recommend to do so. The OBS will automatically use this version which is provided by the openSUSE release. It gets tricky for versions like openSUSE 42.3 which has provided two versions within the same release.

In the future, when (hopefully) with PHP8 we will switch over to a unified directory layout for pear packages (/usr/share/php/PEAR instead of /usr/share/php[578]/PEAR ) it will not make any difference which PHP version has been used for packaging!


Eric Schirra's avatar

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?


Johannes Weberhofer's avatar

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.


Eric Schirra's avatar

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?


Johannes Weberhofer's avatar

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.


Eric Schirra's avatar

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


Johannes Weberhofer's avatar

Where do you see that?


Eric Schirra's avatar

After change require in an package from me.

See in php7 spec file from Leap 15.1 update repo.


Johannes Weberhofer's avatar

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


Arjen de Korte's avatar

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.


Arjen de Korte's avatar

You don't. This will sort itself out depending on the PHP version that is used by the repository.

Instead of branching packages from server:php:applications, consider adding this repository as a source. That will relieve you of having to keep the packages up-to-date and will also prevent breakage in the future. In that case you only need to copy packages you wish to keep at a certain version because an application is not compatible with a newer version.


Arjen de Korte's avatar

I think we should also announce a date when the php[57]-pear- packages will be deleted from this repository. As long as the old packages are there, they will be used.

I think it would also help to write some lines about why linking/branching packages from this repository is not a good idea. If one needs more than a handful of packages from a repository, it should be added as a source, rather than linking/branching separate packages.

  • it reduces the load on the buildservers (as packages are only build in the origin repository)
  • you don't have to keep the packages up-to-date yourself

Only use the provides php-pear(channelname/packagename) to pull in Requires/Recommends in your repository. Under no circumstance use the packagename.


Johannes Weberhofer's avatar

I would remove Leap 42.3 from the repository. Are there any objections against?




Dirk Stoecker's avatar

Could someone please accept or reject that many submissions. Having more than 100 submissions makes it hard for me to handle other projects.


Johannes Weberhofer's avatar

@ralflangb1 is working on those. I hope he finds some time, soon.


Ralf Lang's avatar

Unfortunately, I still did not find a sensible migration path for the packages. By this point in time, I suggest, we drop the packaged versions of horde and just ask users to get them through composer. In case we find a reasonable way to deal with it, I will submit new packages.


Johannes Weberhofer's avatar

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


Eric Schirra's avatar

And why? Imho it's alive.


Johannes Weberhofer's avatar

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


Carsten Ziepke's avatar

Maybe it is time to remove Leap 15.1, 15.2, 15.3 and SLE_12_SP4.


Robert Munteanu's avatar

Why do you suggest those flavours? Not sure about SLE_12_SP4, but Leap 15.3 is still supported.


Carsten Ziepke's avatar

You are right, Leap 15.3 EOL is now 31.12.22 (was 30.11.22).


Arjen de Korte's avatar

I disabled the builds for Leap 15.1 and 15.2. As already mentions, Leap 15.3 is not EOL-ed yet and neither is SLE_12_SP4 (we're actually missing SLE_12_SP5 here, although I'm not sure how relevant this is).

openSUSE Build Service is sponsored by