Le Ven 8 Juillet 2005 18:28, Charles Fry a écrit : > Pierre, > > I was about ready to write my own PEAR packaging reocmmendations > document, when I realized that I agree with all of the points that > you make in your document: > > http://www.madism.org/debian.pear.php > > Are you still attempting to actively maintain your document? I do, and I'm on the webapp list too ;) > 2.1: > 2.5: ack > 2.6: > - why is libxml-xpath-perl a dependency (probably just something > dumb I missed)? for the xslt/xpath magic in maintainer scripts. > However, sections 2.2 through 2.5 seem unnecessarily complicated. > Specifically, they unnecessarily create a new package.tgz file, > unnecessarily creates a new copy of package.xml, and unnecessarily > create dynamic postinst/prerm scripts. :-( the reason is twofold : * I want that the .deb package has the knowledge of the files within the pakage, so that dpkg -L php-foo will work * I want that pear knows that the package is installed. When it's a pure php package, it's quite easy, but nothing tells that one day pear packages won't do some things more elaborated than just copying .php files, so I prefer to register it through PEAR, so that we won't bother with that part. Note that the RPM way to package pear packages (alas the one they recommend) does not fulfill my first point : their rpm does not have the knowledge of the installed files, since it containes the .tgz, and only use pear in order to install. This is really bad, since it will break debsums and other programs like that (I mean, not break in the sense that it won't work, but a sysadmin won't be able to rely on debsums output since those files won't be registered in debsums DB). > While I certainly appreciate the effort you spent getting that to > work, it appears that there are other, simpler solutions. Inasmuch as > I am interested in having a well documented set of best practices, I > would like to see the simplest reasonable solution recommended. Maybe there is much simpler, but the way I described is the only one I could see that fulfill the two points I told about. > Sections 2.3 and 2.4 do nothing more than insert the package name > into the template. It seems more straightforward to me to simply > create static (rather than dynamic template based) watch and postrm > files that contain the package name. sure, my fancy things permits an easier method to write a dh-make-php. that's all (since it has quite nothing to do, the templates are always the same). > 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 > > As far as I can tell, this accomplishes the same thing as your > scripts, with less work. sadly enough (in my real life, I get married last saturday) I didn't had the time to look at those, but if they achieve the same work as mine, and that those are simpler, then those are better ;) > Second, I'm curious to know how interested you are in actively > modifying your webpage (if you agree with some of these ideas). I am, and since I'm now a DD, it would live on my people.d.o page of course. > I'd rather not go to the trouble of making yet another Debian Pear > policy page if we can get by with yours, but I must admit that I am > troubled by the major issues that I've brought up here. I hope you understand a bit what I did and why I did it. (I should say I'm particulary proud of the XSLT extraction of the Changelog that would else be a pain for the maintainer to maintain) > That said, I am immensely greatful for your thoroughness in putting > your Pear policy page together. You seem to have covered all of the > relevant issues in a very resonable manner. I hope so. I'll try to put a less fancy version (graphically speaking) on the webapps CVS soon, and I'll install a checkout on my p.d.o page. just let me 2/3 days to do that (so that my real life things can go on too), and so other webapps policy guys will be able to amend it themselves (I prefer collaborative and sane work than autocraty and that you guys would have to go through me for every little modification) hope that helps. -- ·O· Pierre Habouzit ··O madcoder@debian.org OOO http://www.madism.org
Attachment:
pgp3H9m9jjVqZ.pgp
Description: PGP signature