> [CC: to dpkg-maint since I don't know whether Klee is subscribed to this > list.] How embarrassing. I created this list months ago intending to use it for coordinating dpkg development, never got around to announcing it, and mis-configured my mail filters so I didn't even know it was being used until Christian cc'd: me on mail to it. Truly unfortunate :-). In general, I tend to agree with Chris's points, with one or two bits of elaboration: > - Unfortunately, Klee has been too busy to work on dpkg for the last > months. (Please don't take this as accusation. Klee did a great job Yes, I've really been a wreck with regard to the Debian project these past few months. My contract work for Apple has been pretty intense, and since it's all Free software, I've tended to prioritize it higher than I probably should in hopes in hopes of increasing Apple's future involvement in the Free software community. My apologies to all those who have had to pick up the pieces where I've been remiss, and to those who've been a victim of my seemingly endless e-mail backlog. That said, I've actually been able to a fair bit of work on dpkg these days; it's just not work I've felt comfortable releasing into 'unstable' so close to the code freeze, and I haven't done a good job of communicating my progress. A lot of my work has been to make dpkg more portable and useful on non-Debian platforms, and to make it usable as part of the Apple-internal build and package management process. [ Please don't spread this beyond this list, but if things go as well as they have so far, it's quite possible that we'll be able to have dpkg shipped (GPL intact) as the internal package management system used by Rhapsody) ]. I'm also doing a fair bit of work to make dpkg more palatable to the BSD folks, though the road there will be a bit more uphill. I know there are some who find this uninteresting, but one of my personal goals is to make dpkg as widely supported as possible --- and so I see this as a major step forward. I'll append a copy of my latest changelog entry for those who may be interested. I've also done a lot of work on a new source package format --- it's still got some major warts, but it does allow for multiple upstream sources, signed patch files, and a number of other useful features. I'd been holding off on uploading it in hopes of fixing the things about it I disliked, but now realize that that was misguided. I'll upload a description and the source sometime this week or weekend. For now, I've appended a description of the control file I'm using for GDB within Apple (give me a chance to explain before you criticize it too harshly, though :-). Now, on to the more specific issues: > - dpkg is hard to compile (at least for me :). I tried doing so a few > days ago but didn't succeed. Yes, this has historically been a real problem. I believe I finally managed to root out the last major build problem in 1.4.1.4 --- I can now take the stock tar file and build it (all the way to .deb files) on a stripped-down Rhapsody machine without error (without dpkg and without perl). I hope this will allow a lot more people to get involved in dpkg development, though I'm afraid the Makefiles are just the start of the dpkg complexity curve, not the end of it. > We cannot close [the bug reports] because "we are not the > maintainer". Though I can't speak for Ian, I personally have no objection to people closing bugs fixed in non-maintainer releases. Anyone making significant changes to dpkg should be presumed to know what he or she is doing, and therefore to be more than capable of processing bug reports as well. So long as I get notification of the bug being closed (so I can verify it if necessary), I appreciate all the help I can get. Now, for Chris's proposals: > - dpkg is not considered as 'native Debian package' anymore, but as > independent package which has (possibly different) upstream maintainers > and a Debian maintainer > - there will be one Debian maintainer who will package up dpkg, who > maintains the bug reports (answers arriving reports, closes them, etc.) > This person could be part of the dpkg dev team, but doesn't necessarily > have to be. He must have enough time for the day-to-day maintenance. > (It currently looks to me like Juan would be the right person for this > job.) > (Note, that if noone should want to take this job, I'd volunteer, too. > However, I'm sure we have developers with better dpkg knowledge > around, who'd do a better job than myself.) Conceptually, I think this would be fine, though I'm not sure it's all that big a change in practice. One of my biggest problems as dpkg maintainer has been that dpkg is a little too important to use 'unstable' as it's primary testing mechanism. This means that I've either been reluctant to make major changes, or that when I do, I'm reluctant to release them beyond 'experimental' (where they go seemingly ignored). I'd love to have someone else around to test changes and to take care of things when emergencies arise, as well as to make major changes of their own. My impression though, is that this list is already serving that purpose --- the only thing wrong is that I need to do a better job of communicating with people. Perhaps we should try that first for a month or so and see how it goes? In the immediate future I have four proposals I'd like to implement this week/weekend: 1) I synch up my changes through 1.4.1.4 with the current 1.4.0.22, check the results into CVS, and upload the result to 'experimental' 2) I close all the bugs Christian mentioned in his original E-mail, plus any others I may have fixed in 1.4.1.4. 3) I upload the (incomplete) source to my new packaging format, and maybe one of us can figure out how to fix the things I hate about it before I start pushing it on debian-policy. 4) I outline my major goals for dpkg development, and we discuss what people think about them, how they might like to see them changes, and how they might want to fit into the development process. Based on the results from (4), we can decide where to go from there. Does this sound reasonable?
Attachment:
dpkg.spec
Description: Binary data
Attachment:
changelog
Description: Binary data