Home > Archive > PHP PEAR Questions and Answers > June 2004 > Re: [PEAR-QA] External Packages x PEAR
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: [PEAR-QA] External Packages x PEAR
|
|
| Adam Gołębiowski 2004-06-29, 4:00 pm |
| On Tue, Jun 29, 2004 at 09:26:14AM -0300, Antônio Carlos Venâncio Júnior wrote:
> People,
>
> do have PEAR any kind of standard regarding external package handling?!
Why should PEAR group care about how different distributions / OSes
handle PEAR/PECL packages?
> Dont't you think it's a good idea to assign people to be responsible
> to maintain the quality of that packages too?!
Which means what exactly? You want to assign someone to take care of
PEAR/PECL packages i.e. here in PLD Linux?
--
http://www.mysza.eu.org/ | Everybody needs someone sure, someone true,
PLD Linux developer | Everybody needs some solid rock, I know I do.
| |
| Lukas Smith 2004-06-29, 4:00 pm |
| Adam Gołębiowski wrote:
> On Tue, Jun 29, 2004 at 09:26:14AM -0300, Antônio Carlos Venâncio Júnior wrote:
>
>
>
> Why should PEAR group care about how different distributions / OSes
> handle PEAR/PECL packages?
>
>
>
>
> Which means what exactly? You want to assign someone to take care of
> PEAR/PECL packages i.e. here in PLD Linux?
Tal Peer has beeing looking after the pear packages in gentoo portage
maybe you can talk to him:
coredumb@gentoo.org
regards,
Lukas Smith
smith@backendmedia.com
_______________________________
BackendMedia
www.backendmedia.com
berlin@backendmedia.com
Linn Zwoch Smith GbR
Pariser Str. 44
D-10707 Berlin
Tel +49 30 83 22 50 00
Fax +49 30 83 22 50 07
| |
| Antônio carlos venâncio júnior 2004-06-29, 4:00 pm |
| Adam,
Adam Gołębiowski wrote:
> On Tue, Jun 29, 2004 at 09:26:14AM -0300, Antônio Carlos Venâncio Júnior wrote:
>
>
>
> Why should PEAR group care about how different distributions / OSes
> handle PEAR/PECL packages?
Because someone ({1,}) inside PEAR (that knows it's internals) will be
responsible for doing whatever whould be needed to correctly generate
the packages and keep them updated.
>
>
> Which means what exactly? You want to assign someone to take care of
> PEAR/PECL packages i.e. here in PLD Linux?
I mean to maintain them.
--
Ate'
Antonio
echo antonio php net | sed 's/ /@/;s/ /./g'
FreeBSD/OpenBSD/Solaris | PHP/MySQL/Python | PGP Key ID 0x5BBEB073
"Can't buy what I want because its FREE!" - Pearl Jam
| |
| Tomas V.V.Cox 2004-06-29, 4:00 pm |
| Do you use in PLD the "pear makerpm" facility? If not what problems did
you find for it and what do you actually use?
Thanks, was always curious about that.
Tomas V.V.Cox
Adam Gołębiowski wrote:
> On Tue, Jun 29, 2004 at 09:26:14AM -0300, Antônio Carlos Venâncio Júnior wrote:
>
>
>
> Why should PEAR group care about how different distributions / OSes
> handle PEAR/PECL packages?
>
>
>
>
> Which means what exactly? You want to assign someone to take care of
> PEAR/PECL packages i.e. here in PLD Linux?
>
| |
| Adam Gołębiowski 2004-06-29, 8:56 pm |
| On Tue, Jun 29, 2004 at 04:32:53PM +0200, Lukas Smith wrote:
> Tal Peer has beeing looking after the pear packages in gentoo portage
> maybe you can talk to him:
> coredumb@gentoo.org
Thanks for the contact. Maybe we will share some thoughts about the way
PEAR packages can be handled, although PLD and Gentoo are totally
different distribution in the way of package managers.
--
http://www.mysza.eu.org/ | Everybody needs someone sure, someone true,
PLD Linux developer | Everybody needs some solid rock, I know I do.
| |
| Adam Gołębiowski 2004-06-29, 8:56 pm |
| On Tue, Jun 29, 2004 at 08:50:03PM +0200, Tomas V.V.Cox wrote:
> Do you use in PLD the "pear makerpm" facility? If not what problems did
> you find for it and what do you actually use?
No we do not. When I took over PEAR packages from its previous
maintainer, I decided to follow his way of doing packages. We have a
group of spec templates (for typical package, library, perl modules,
etc). Personally I added two more templates - one for PEAR package, one
for PECL extensions. Each class/extension has its own spec and its build
process is rather independent. We also have a set of two rather simple
scripts for generating dependencies based on package.xml file. Uhm,
actually these scripts are finished, and they work when run from command
line, but when called while building package they are terminated with
some strange error... still to be figured out.
> Thanks, was always curious about that.
If anyone wants to have a look, our specs are available and
http://cvs.pld-linux.org/SPECS/template-php-pear.spec and
http://cvs.pld-linux.org/SPECS/template-php-pecl.spec. I am also curious
of what you think of such way of distributing PEAR packages.
And for the question - why not pear makerpm. Hmm... well, how could we
control it? It wouldn't fit to our infrastructure - that's for sure.
Second, what would be the benefit?
--
http://www.mysza.eu.org/ | Everybody needs someone sure, someone true,
PLD Linux developer | Everybody needs some solid rock, I know I do.
| |
| Adam Gołębiowski 2004-06-29, 8:56 pm |
| On Tue, Jun 29, 2004 at 03:10:49PM -0300, Antônio Carlos Venâncio Júnior wrote:
> Because someone ({1,}) inside PEAR (that knows it's internals) will
> be responsible for doing whatever whould be needed to correctly generate
> the packages and keep them updated.
I am afraid this would slow down release process. Imagine there's
package to be released. Theoretically before it happens there should be
response from the group of people responsible for maintaing packages in
various distributions.
>
> I mean to maintain them.
Uhm, don't get me wrong, but my statement is: If a distribution wants to
include PEAR packages, it should take care of it on their own. If there
are any suggestions or improvements, they will send them to appropriate
people. This how it happens with other software. We do not require Linus
to mess up with our kernel :)
I simply think that it would be waste of your time - better spend it
developing it PEAR packages, making them even better then they are :)
--
http://www.mysza.eu.org/ | Everybody needs someone sure, someone true,
PLD Linux developer | Everybody needs some solid rock, I know I do.
| |
| Tomas V.V.Cox 2004-06-30, 3:57 pm |
| Adam Gołębiowski wrote:
> On Tue, Jun 29, 2004 at 08:50:03PM +0200, Tomas V.V.Cox wrote:
>
> We also have a set of two rather simple
> scripts for generating dependencies based on package.xml file. Uhm,
> actually these scripts are finished, and they work when run from command
> line, but when called while building package they are terminated with
> some strange error... still to be figured out.
I remember long time ago a guy (maybe from PLD) doing that by "grepping"
the XML in a bash script. In case you're interested on how to do that
natively, a quick example:
$ php -r 'include "PEAR/Common.php"; $c=new PEAR_Common;
$i=$c->infoFromAny("./package.xml"); print_r($i["deps"]);'
(The deps generation for "makerpm" is still missing, yes)
>
>
>
> If anyone wants to have a look, our specs are available and
> http://cvs.pld-linux.org/SPECS/template-php-pear.spec and
> http://cvs.pld-linux.org/SPECS/template-php-pecl.spec. I am also curious
> of what you think of such way of distributing PEAR packages.
>
> And for the question - why not pear makerpm. Hmm... well, how could we
> control it? It wouldn't fit to our infrastructure - that's for sure.
"pear makerpm" does generate a .spec file, you can mutate for your
distrib. If you want even low level access, in cvs:
pear-core/template.spec, you have the source file we use for generating
the rpm.
> Second, what would be the benefit?
It's relative dangerous to install PEAR packages without the pear
installer. Mostly for:
1) PEAR packages do replacements in files
2) The user may want to install the packages shipped with PLD, but
upgrade or install newer ones with the "pear installer". If you don't
register it's deps, would hardly work.
3) In general using the pear installer will make your life more easy in
the future.
I'd be glad to hear suggestions and improvements for the RPM generation,
was coded mostly for helping Linux distributions, and anyone (AFAIK) is
using it, spending a lot of efforts on home-made package converters with
IMHO not very high quality results.
Tomas V.V.Cox
| |
| Antônio carlos venâncio júnior 2004-06-30, 3:57 pm |
| Adam,
Adam Gołębiowski wrote:
> On Tue, Jun 29, 2004 at 03:10:49PM -0300, Antônio Carlos Venâncio Júnior wrote:
>
>
>
> I am afraid this would slow down release process. Imagine there's
> package to be released. Theoretically before it happens there should be
> response from the group of people responsible for maintaing packages in
> various distributions.
Sorry, but both are totally different things. One thing has nothing
about the other. We will be releasing packages normally, then some
people (who will be maintaining the external packages) will be
responsible to generate them. That with no hurry, as it's alreay done today.
There are some external PEAR packages that are not syncronized with the
original ones. And that applies to all other applications at FreeBSD's
port collection (for example).
The point here is to make them with quality.
>
>
> Uhm, don't get me wrong, but my statement is: If a distribution wants to
> include PEAR packages, it should take care of it on their own. If there
> are any suggestions or improvements, they will send them to appropriate
> people. This how it happens with other software. We do not require Linus
> to mess up with our kernel :)
>
> I simply think that it would be waste of your time - better spend it
> developing it PEAR packages, making them even better then they are :)
Actually it's not a waste of time, since the packages are easily
"managable" - and the PEAR ones are easier because its installer does
the hard job. ;)
--
Ate'
Antonio
echo antonio php net | sed 's/ /@/;s/ /./g'
FreeBSD/OpenBSD/Solaris | PHP/MySQL/Python | PGP Key ID 0x5BBEB073
"Can't buy what I want because its FREE!" - Pearl Jam
| |
| David Costa 2004-06-30, 3:57 pm |
| snip
On Jun 30, 2004, at 1:15 PM, Ant=F4nio Carlos Ven=E2ncio J=FAnior wrote:
>
> Sorry, but both are totally different things. One thing has =
nothing=20
> about the other. We will be releasing packages normally, then some=20
> people (who will be maintaining the external packages) will be=20
> responsible to generate them. That with no hurry, as it's alreay done=20=
> today.
> There are some external PEAR packages that are not syncronized =
with=20
> the original ones. And that applies to all other applications at=20
> FreeBSD's port collection (for example).
> The point here is to make them with quality.
>
I am probably lost. What would be the advantage of doing all this when=20=
you can simple log into your BSD box and run pear install .... etc ?
Cheers
David Costa
| |
| CtĂşîk «gňns‰üĺnĘniéo&äĂşnkr 2004-06-30, 3:57 pm |
| David,
David Costa wrote:
> snip
> On Jun 30, 2004, at 1:15 PM, Antônio Carlos Venâncio Júnior wrote:
>
>
>
> I am probably lost. What would be the advantage of doing all this when
> you can simple log into your BSD box and run pear install .... etc ?
There's no problem with that. The ports are there because some people
requested them to be used via ports and because sometime its needed to
(to work correctly with FreeBSD):
----------
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/67461
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/53522
----------
Again, the point here is to make them with quality.
> Cheers
> David Costa
--
Ate'
Antonio
echo antonio php net | sed 's/ /@/;s/ /./g'
FreeBSD/OpenBSD/Solaris | PHP/MySQL/Python | PGP Key ID 0x5BBEB073
"Can't buy what I want because its FREE!" - Pearl Jam
| |
| David Costa 2004-06-30, 3:57 pm |
|
On Jun 30, 2004, at 1:41 PM, Ant=F4nio Carlos Ven=E2ncio J=FAnior wrote:
> David,
snip
[color=darkred]
[color=darkred]
[color=darkred]
> There's no problem with that. The ports are there because some =
people=20
> requested them to be used via ports and because sometime its needed to=20=
> (to work correctly with FreeBSD):
>
Thanks for your reply Antonio. I understand that for some people this=20
might be a good extra, but is hardly a need. Of course if a user=20
decide to use the ports in lieu of our
installer, then it expose itself to a possible quality problem. I think=20=
that such packaging makes sense but up to a point. Beats me why=20
someone couldn't be happier with the pear
installer and simply run pear install .........
I don't think that PEAR QA (which has already some major issues to=20
tackle) should be responsible for third party repackaging.
Cheers
David Costa
> ----------
> http://www.freebsd.org/cgi/query-pr...r=3Dports/67461
> http://www.freebsd.org/cgi/query-pr...r=3Dports/53522
> ----------
>
> Again, the point here is to make them with quality.
>
> --=20
> Ate'
>
> Antonio
> echo antonio php net | sed 's/ /@/;s/ /./g'
> FreeBSD/OpenBSD/Solaris | PHP/MySQL/Python | PGP Key ID 0x5BBEB073
> "Can't buy what I want because its FREE!" - Pearl Jam
>
> --=20
> PEAR QA Mailing List (http://pear.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
| |
| CtĂşîk «gňns‰üĺnĘniéo&äĂşnkr 2004-06-30, 3:57 pm |
| David,
David Costa wrote:
>
> On Jun 30, 2004, at 1:41 PM, Antônio Carlos Venâncio Júnior wrote:
>
> snip
>
>
>
>
> Thanks for your reply Antonio. I understand that for some people this
> might be a good extra, but is hardly a need. Of course if a user decide
> to use the ports in lieu of our
> installer, then it expose itself to a possible quality problem. I think
> that such packaging makes sense but up to a point. Beats me why someone
> couldn't be happier with the pear
> installer and simply run pear install .........
I dunno too. hehe
> I don't think that PEAR QA (which has already some major issues to
> tackle) should be responsible for third party repackaging.
OK. If someday PEAR QA decide to take care about it, I would take the
responsible for this "repackaging" for FreeBSD.
[color=darkred]
> Cheers
> David Costa
>
--
Ate'
Antonio
echo antonio php net | sed 's/ /@/;s/ /./g'
FreeBSD/OpenBSD/Solaris | PHP/MySQL/Python | PGP Key ID 0x5BBEB073
"Can't buy what I want because its FREE!" - Pearl Jam
| |
| Adam Gołębiowski 2004-06-30, 3:57 pm |
| On Wed, Jun 30, 2004 at 01:25:20PM +0200, David Costa wrote:
> snip
> On Jun 30, 2004, at 1:15 PM, Antônio Carlos Venâncio Júnior wrote:
>
>
> I am probably lost. What would be the advantage of doing all this when
> you can simple log into your BSD box and run pear install .... etc ?
Well, obviously using pear command line is an easy way to install pear
packages, but ...
.... we also distribute some packages (like agata or dotproject) that
require some of PEAR classes. Now, if we dropped PEAR classes from
distribution, we would also have to drop those package who require them,
since we wouldn't have any mechanism to satisfy those dependencies. And
we cannot do pear install in post-installation scripts since we cannot
rely that user have internet connection.
Hmm... or maybe we could...
--
http://www.mysza.eu.org/ | Everybody needs someone sure, someone true,
PLD Linux developer | Everybody needs some solid rock, I know I do.
| |
| Adam Gołębiowski 2004-06-30, 3:57 pm |
| On Wed, Jun 30, 2004 at 12:53:54PM +0200, Tomas V.V.Cox wrote:
> Adam Gołębiowski wrote:
>
> I remember long time ago a guy (maybe from PLD) doing that by "grepping"
> the XML in a bash script.
Yeah, we had that. Now we have as a set of two simple perl scripts...
> In case you're interested on how to do that
> natively, a quick example:
>
> $ php -r 'include "PEAR/Common.php"; $c=new PEAR_Common;
> $i=$c->infoFromAny("./package.xml"); print_r($i["deps"]);'
Oh, didn't now that. Thanks. I will think of replacing our dependencies
generator with something native. But I don't how the rest of the team
will react on such idea. We'll discuss this.
>
> It's relative dangerous to install PEAR packages without the pear
> installer. Mostly for:
>
> 1) PEAR packages do replacements in files
We track these.
> 2) The user may want to install the packages shipped with PLD, but
> upgrade or install newer ones with the "pear installer". If you don't
> register it's deps, would hardly work.
Oh, the same happens if user installs libfoo by himself (by compiling
from sources). There wouldn't be a clue about it in RPM database and an
attempt to install anything that depends on it would fail.
> 3) In general using the pear installer will make your life more easy in
> the future.
But it's not that easy to incorporate it into our infrastructrure. The
same applies to CPAN.
> I'd be glad to hear suggestions and improvements for the RPM generation,
> was coded mostly for helping Linux distributions, and anyone (AFAIK) is
> using it, spending a lot of efforts on home-made package converters with
> IMHO not very high quality results.
But... making rpm conflicts with what you wrote in point 2) :)
--
http://www.mysza.eu.org/ | Everybody needs someone sure, someone true,
PLD Linux developer | Everybody needs some solid rock, I know I do.
| |
| Michael Wallner 2004-06-30, 3:57 pm |
| Hi Adam Gołębiowski, you wrote:
> Well, obviously using pear command line is an easy way to install pear
> packages, but ...
>
> ... we also distribute some packages (like agata or dotproject) that
> require some of PEAR classes. Now, if we dropped PEAR classes from
> distribution, we would also have to drop those package who require them,
> since we wouldn't have any mechanism to satisfy those dependencies. And
> we cannot do pear install in post-installation scripts since we cannot
> rely that user have internet connection.
>
> Hmm... or maybe we could...
>
Just an idea of an idea:
I don't know the internals of RPM packaging etc. or if it's
just silly - nevermind :)
Only maintain the PEAR package as you did and introduce some
automatic packaging(*) of other other PEAR packages tarballs
with the only installation step of
$ pear install /path/to/temporary/Package.tgz
So only the PEAR base package would have to be maintained
and all other packages can be "ported" automatically.
(*)
pear download package
whatever-makerpm package.tgz
Regards,
--
Michael - < mike(@)php.net >
| |
| Tomas V.V.Cox 2004-06-30, 8:58 pm |
| Adam Gołębiowski wrote:
> On Wed, Jun 30, 2004 at 12:53:54PM +0200, Tomas V.V.Cox wrote:
>
>
>
>
> Oh, didn't now that. Thanks. I will think of replacing our dependencies
> generator with something native. But I don't how the rest of the team
> will react on such idea. We'll discuss this.
Will be glad if you contribute the code for generating them. As well I
could help you on that if you give some output samples (yes, lazy enough
for trying to avoid reading RPM Maximun ;)
>
>
>
> We track these.
Don't you feel like reiventing the PEAR installer in perl or bash? ;)
>
>
>
> Oh, the same happens if user installs libfoo by himself (by compiling
> from sources). There wouldn't be a clue about it in RPM database and an
> attempt to install anything that depends on it would fail.
Yes, that's true, but as we will always faster generating PEAR packages
than you (you know, we code them), I see a place for a nice "living
together" systems.
Apart from that, our generated .spec file does not actually install any
file, we leave that to rpm. Have you take a look at it?
>
>
>
> But it's not that easy to incorporate it into our infrastructrure. The
> same applies to CPAN.
In not too far, we'll get pre/post scripts or a real dependency db, for
saying some stuff that will give you more "troubles".
>
>
> But... making rpm conflicts with what you wrote in point 2) :)
I doubt that could be a problem if we get PEAR installer to register the
dep in the rpm db, using --justdb rpm option or something like so.
Anyway, was just trying to help you, for us would be much more easy to
just drop RPM support if it tends to be useless for people like you.
Tomas V.V.Cox
|
|
|
|
|