[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: maintenance of dpkg (Re: I've verified some dpkg bugs)

> [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 --- 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 with the current, check the results into CVS, and upload the result to

2) I close all the bugs Christian mentioned in his original E-mail,
   plus any others I may have fixed in

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

Reply to: