[opensuse-packaging] Creating server:php:applications:pear and moving pear packages there?
Hi packagers, are there any objections to moving pear packages (which are quite a lot) from server:php:applications to a new sub project server:php:applications:pear ? -- Ralf Lang Linux Consultant / Developer B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi Ralf, At dinsdag 25 januari 2011 10:16:08 wrote Ralf Lang:
are there any objections to moving pear packages (which are quite a lot) from server:php:applications to a new sub project server:php:applications:pear ?
I created some of them for the groupware server Kolab (http://kolab.org). It is okay with me, if they'll be put in their own repository. Some questions thoughts; What does that mean for the maintainers? Sometimes one need to have access to both pear and php packages as sometimes a PHP package is a dependency for pear packages. It will therefore more difficult to add packages as an additional needs to be configured on the client (user) system. Is the latter acceptable (desired, etc)? -- Richard -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Am Dienstag 25 Januar 2011, 17:51:00 schrieb Richard Bos:
Hi Ralf,
from server:php:applications to a new sub project server:php:applications:pear ?
I created some of them for the groupware server Kolab (http://kolab.org). It is okay with me, if they'll be put in their own repository. Some questions thoughts; What does that mean for the maintainers? Sometimes one need to have access to both pear and php packages as sometimes a PHP package is a dependency for pear packages. It will therefore more difficult to add packages as an additional needs to be configured on the client (user) system. Is the latter acceptable (desired, etc)?
If we talk about the packaging process, this might be an issue but can be configured in the OBS GUI. If we talk about end users, shouldn't we aim to get pear packages into factory anyway? Currently, I need to include both server:php:extensions and server:php:applications even if I want to run php software from tarballs but want to have a clean (rpm-based) pear/pecl. That wouldn't change if it was s:p:a:pear. Applications would be yet another repo but I find that acceptable. Would you search for a bunch of common libraries in something called application? I'm not sure, that's why I asked. -- Ralf Lang Linux Consultant / Developer B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
At woensdag 26 januari 2011 09:27:10 wrote Ralf Lang:
Am Dienstag 25 Januar 2011, 17:51:00 schrieb Richard Bos:
Hi Ralf,
from server:php:applications to a new sub project server:php:applications:pear ?
I created some of them for the groupware server Kolab (http://kolab.org). It is okay with me, if they'll be put in their own repository. Some questions thoughts; What does that mean for the maintainers? Sometimes one need to have access to both pear and php packages as sometimes a PHP package is a dependency for pear packages. It will therefore more difficult to add packages as an additional needs to be configured on the client (user) system. Is the latter acceptable (desired, etc)?
If we talk about the packaging process, this might be an issue but can be configured in the OBS GUI. If we talk about end users, shouldn't we aim to get pear packages into factory anyway?
Currently, I need to include both server:php:extensions and server:php:applications even if I want to run php software from tarballs but want to have a clean (rpm-based) pear/pecl. That wouldn't change if it was s:p:a:pear. Applications would be yet another repo but I find that acceptable.
Would you search for a bunch of common libraries in something called application?
I'm not sure, that's why I asked.
One just uses openSUSE search independent of a repository to find were the package is located. And whether a pear packages is located in s:p:a or in s:p:pear doesn't matter to the end user I think. It might already be confusing that it is in server: something. The pear packages BuildRequires php packages (at least some require php5, eg: php-pear-net_smtp and php-pear-net_lmtp), in such cases it is easy if the packages are in the same repository. However, if the s:p:pear can use the s:p:a repository just after checking out (because it is e.g. configure in the proj file) than it is fine with me. -- Richard -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Wednesday 26 January 2011 09:27:10 Ralf Lang wrote:
are there any objections to moving pear packages (which are quite a lot) from server:php:applications to a new sub project server:php:applications:pear
What are the benefits you forsee in doing this? If there are clearly demonstrable benefits then I might be in favour of it.
Would you search for a bunch of common libraries in something called application?
Except PEAR pear packages can, and in fact are, sometimes more than just libraries. Applications get bundled using pear channels too. phpDocumentor, php codesniffer are two that immediately spring to mind. How would you make the distinction between something like phpDocumentor & php codesniffer (both applications) and something else which is clearly a libary? Do we then search for applications in s:p:applications except if we remember the applcation might be in pear? What about other utilities/apps/libaries that may be bundled with an installble pear channel? I feel this is going to lead to confusion I don't see any immediate benefit from this. -- “What can be asserted without proof can be dismissed without proof.” - Christopher Hitchens -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 2011-01-25 10:16:08 +0100, Ralf Lang wrote:
are there any objections to moving pear packages (which are quite a lot) from server:php:applications to a new sub project server:php:applications:pear ?
i dont see any benefit from having a pear project. strictly speaking the pear stuff should have gone to s:php:extensions to begin with, so if you wanted to move them anywhere, it should be that project. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
strictly speaking the pear stuff should have gone to s:php:extensions to begin with, so if you wanted to move them anywhere, it should be that project.
That would be a bad thing, as s:php:extensions is pecl (c-code extensions to the php interpreter) and pear is about php code.
Except PEAR pear packages can, and in fact are, sometimes more than just libraries. Applications get bundled using pear channels too. phpDocumentor, php codesniffer are two that immediately spring to mind.
Do we then search for applications in s:p:applications except if we remember the applcation might be in pear? What about other utilities/apps/libaries
The applications-as-pear-package thing is really a good argument. Horde just announced yesterday that they will also release their upcoming H4 release (April 2011) as a set of pear packages from their own channel. that
may be bundled with an installble pear channel?
No, that would be no option. -- Ralf Lang Linux Consultant / Developer B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
participants (4)
-
Graham Anderson -
Marcus Rueckert -
Ralf Lang -
Richard Bos