> > > I did, however, notice that the package.xml file must be in the > > > same directory as the package files. Perhpas this is best > > > accomplished by symlinking package.xml, and then modifying the > > > install command to be something like: > > > > > > pear install --nodeps -R debian/php-pager > > > Pager-2.3.3/package.xml > > > > except for the --nodeps part, it may be correct > > I actually think that the --nodeps is correct. The depenencies need > to be there to use the package, but not necessarily when creating the > .deb. Let Debian handle the dependencies (both at build and install > time). well, I disagree : if a pear package has changing deps, the maintainer may miss those, and the bug could be hard to find. whereas a failing postinst is more easy to debug IMHO. so relying on PEAR dependency scheme may not be that bad... though maybe some curious things may happen if you are installing many PEAR packages at the same time. so maybe you are right ... > I absolutely agree that pear install should be used to install all > pear packages. I simply differ in how I think this should happen. > Specifically: > > 1) Rather than using "pear install package.tgz" I am suggesting > "pear install package.xml". > > 2) Rather than running "pear install -r package.xml" on a > cached version of package.xml, I am suggesting that the .registry > file be installed in the .deb. point is, .registry is a PEAR internal. and if the PEAR .registry format changes, then if the .registry files are part of the package, you have: * either to repackage every PEAR package (painful) * or make php-pear update every .registry file (I suppose in those cases upstream would have the required script) which would make every debsum fail for those files ... nasty proprerty IMHO. add to that, that having the .registry in the listing of the package IMHO sucks. for the rest, I think I agree you do everything that has to be done, and much simplier than me. but please think at the .registry again. let think at the fact that PEAR may change their packaging format/methods without warning ... and if they do that ... let's say ... 2-3 monthes before etch ... that would *really* suck ... > I recognize that I might be missing something which prevents my > approach from working, in which case I welcome your feedback and > suggestions. :-) It does not prevent it to work, it prevent it to upgrade smoothly in case of ... upstream mood swing pear install -R/r/whathever_options does create the right .registry files. it's PEAR internals, PEAR way's of keeping track of what is installed, ... let it deal with its stuff, and don't bother checking it, it's not our stuff (we even don't want to have .registry/ directory be listed as a directory of the package and see it destroyed or some horror alike). I agree with you for all the rest, but I'm still convinced we *have* to let PEAR deal with its stuff, it's his job, his own, his dirty personnal intimate one. You don't want seriously to toy with it (IMHO). -- ·O· Pierre Habouzit ··O madcoder@debian.org OOO http://www.madism.org
Attachment:
pgpOX5TCiSorI.pgp
Description: PGP signature