> > > As for section 2.2, Uwe's dh-make-php uses the following command to > > > install the pear package: > > > > > > pear install --nodeps -R $(CURDIR)/debian/$(PACKAGE_NAME) > > > package.xml > > > > Reading "pear help install", this install mechanism is specifically > > recommended for "testing, or for wrapping a PEAR package in > > another package manager such as RPM." > > I know that, but if the maintainer screwd up, and that he forgot some > Depends on its package, the postinst will fail (if you don't specify > --nodeps) and my packaging is also more robust. I should have been more clear. I am suggesting the use of this line to replace the current: pear install -n -R debian/$(package)/ debian/package.tgz in debian/rules. The point is that there is no need to recreate package.tgz; you can simply use package.xml, as long as it is in the same directory as the archive files, which can be handled with a symlink. > > 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). > > One other minor thing, is it really correct to remove the .registry > > directory? As far as I can tell, that should actually be maintained. > > yes it is, because I don't want them to be registered in the .deb > content. those are created by my call (in postinst) of pear. I might be missing something, but it appears to me that registering a Pear module simply consists of creating a file in the .registry directory. Inasmuch as the file contents would be the same in either case, it does not seem incorrect to me to create that file in the .deb, and then for it to be installed with the package. Further, this simplifies installation as it is no longer necessary to hold onto package.xml. > Note that atm `pear install' only creates new files. but the day it will > begin to modify an existing file, packaging without my fancy > prerm/postinst will be unpossible (sorry, the sentence may not be very > "english" I don't know how to explain it very clearly, but you should > see the point). 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. > my packaging method *is* complex, but is also very robust to any > uncompatible pear modifications : it makes really less assumptions on > pear than you do (as I understand it, but again, I've not looked cleary > what you do and how you do it, so I may misunderstand sth). Your robustness comes from your use of pear install, which I support. I am simply suggesting a simpler use of pear install, which maintains all of your advantages. Why don't you take some time to examine my suggestions in greater detail, and maybe to try them out yourself. You can also examine my php-pager package at: http://debian.frogcircus.org/packages/ (Note that php-cache-lite was created with dh-make-php, while php-pager started that way and was then modified to include the changes that I am currently suggesting (which actually involves merging your recommendations with the fine setup that dh-make-php provides).) I recognize that I might be missing something which prevents my approach from working, in which case I welcome your feedback and suggestions. :-) Charles -- To change that Shaving job To joy You gotta use The real McCoy Burma-Shave http://burma-shave.org/jingles/1955/to_change_that
Attachment:
signature.asc
Description: Digital signature