Pierre, Thanks for your response. :-) Perhaps I explained myself poorly, but I don't disagree with you nearly as much as you think; rather I am suggesting a simpler means (thanks to Uwe) for accomplishing the same thing. > > 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 Absolutely. In addition to this, it seems to me that it makes it easier to make changes to the upstream source, and to be able to understand them when viewing the .diff.gz. > * 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. Again, I agree completely. Another advantage of this is that pear can be used to install packages that aren't in Debian, and still be able to track dependencies on packages that were installed with Debian. > 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). This is a bad thing in RPM-land. I also think it is a problem with the current pear-package program (which contains the .tgz), and with the current dh-make-php program (which changes the original .tgz). Hopefully coming to consensus on best practices here will lead to consistent implementations in various tools. > > 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. I agree that we must fulfill those points; and yes, I think there is a simpler way! > > 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). Definitely clever, but I argue that it is unnecessarily complex for a best practices guide. I must admit that it does bother me that prerm is dynamically generated. I thought I remembered some recent mailing list discussion or anouncement somewhere about the badness of dynamically generating certain Debian files, but I don't remember the details. It just seems like a generally bad thing to me. > > 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 ;) Congratulations on your real life! I also have a family that takes priority over Debian. As explained in the follow up email I sent, in addition to achieving the same thing, this command does it in a simpler way. > > 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. Cool! > > 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) I both understand and admire what you did; I just think that there is a simpler way to deal with package.xml, while avoiding a new tgz. :-) > 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) Excellent. That sounds like the way to go. Charles -- Soap's That irritate Their mugs Turn jolly gents To jitterbugs Burma-Shave http://burma-shave.org/jingles/1939/soaps
Attachment:
signature.asc
Description: Digital signature