On Wed, Aug 19, 2009 at 10:11:12AM +1000, Ben Finney wrote: > Sune Vuorela <email@example.com> writes: > > > For example, I would be very reluctant to sponsor a first package of a > > person that was a new library without any application using it, > > whereas a interesting kde application might easier catch my eye. > > That's interesting, thank you for that perspective. What do you propose, > then, for a maintainer who wants to get a new package into Debian, but > that package requires one or more separately-packaged libraries that > *also* need to be sponsored into Debian before the “interesting” package > can go in? I've had to do this with Perl modules once - I wanted to package a particular module, but it had a chain of dependencies that were not packaged yet. What I did was file a series of ITP bugs, stating my intentions clearly - first for the "target" package, saying "This module also needs So-And-So and This-And-That, which will be ITP'd separately", and then for the dependencies, each ITP stating "This module is needed for the packaging of So-And-So (ITP #NNN)". A couple of days later, helpful people from the Debian Perl Group did the last part that I'd missed - made the ITP bugs block one another in the proper order. Thus, anyone who reads the library bug sees "it is needed for ITP #NNN", and anyone who reads the original ITP bug sees "blocked by #NNN" and knows why it hasn't been RFS'd yet. G'luck, Peter -- Peter Pentchev firstname.lastname@example.org email@example.com roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I've heard that this sentence is a rumor.
Description: PGP signature