Hi Piotr, On Tue, Apr 15, 2003 at 03:15:56PM +0200, Piotr Roszatycki wrote: > A week ago James rejected my PEAR packages. I need this packages because > there are newer version than libraries in php4-pear package. There are > used by IMP and other applications. I don't like to install PEAR > repository with bundled 'pear' installer as far as I've got Debian > packaging system. > I see analogy to Perl CPAN libraries. There are stable versions of CPAN > libraries in perl-modules package. There are also newer libraries in > separate packages, i.e. libcgi-pm-perl has newer CGI.pm. > My questions: > 1. Should it be one package updated very often or several tiny packages > with dependencies and original version numbers? > 2. What schema for package names? At the time, James talked to Adam Conrad and me about the packages, and we agreed with the decision to hold the packages out of the archive for the time being. For one thing, it looks like you packaged *all* PEAR modules available, including some of questionable merit (I seem to recall seeing one called 'db-ldap'). Do you actually need *all* of these modules? This, I think, is the main objection: if the software will actually be used, then I don't object to having them in the archive; I just have difficulty believing that all of the packages you uploaded are actually useful. Because the upstream software will release separately, I think it's ok to have separate packages for each module, just as we have with CPAN. However, to your second question: 'pear' should not be listed in the package name, just as 'cpan' is not listed in the names of Perl modules. This is the distribution mechanism, and tells us nothing about function. Better to mimic perl and use a 'libphp-<class>' naming scheme. > 3. Which directory for PEAR libraries? PEAR classes should be installed to /usr/share/php and subdirectories. As long as you're only uploading packages for classes you need, I think it should be ok for these to go into the archive. I think this should include any PEAR classes no longer distributed with PHP 4.3.x, as well as any classes that you need newer versions of than what's provided in PHP 4.3.x; however, if the version from 4.2.3 is too old, but the version from 4.3.0 is new enough, I would ask that you not upload these, since PHP 4.3 should be available soon. Regards, -- Steve Langasek postmodern programmer
Attachment:
pgp0G4TvUrIzJ.pgp
Description: PGP signature