On Sun, 1 Jul 2007 09:58:52 +0000 (UTC) Kumar Appaiah <akumar@ee.iitm.ac.in> wrote: > Neil Williams <codehelp <at> debian.org> writes: > > > I am looking for a sponsor for the new version 3.99.2-1 > > > of my package "libitpp". > > When asking for a sponsor, please mention whether the package already > > exists in Debian - i.e. whether you have had a sponsor who is now busy > > etc. > > OK, so this is the last time I rely on the template in Mentors. Anyway, I > thought the "updated" subject line would do, but it's OK. That's the thing with templates - they are meant to be edited. ;-) Do please use the template, just ensure that you add sufficient information to the template for your specific request and check that every single part of the template is accurate *before* clicking Send. > > A -dbg package needs to be provided. > > (-dbg packages are likely to become mandatory by Lenny.) > > Will look into this. It should be a simple addition to dh_strip: dh_strip --dbg-package=libfooSONAME-dbg and then the content in debian/control -dbg packages should usually be priority extra if the package is optional or optional|extra for higher priorities. > > There is 500kb of source in the doc/ directory and probably more by the > > time the generated HTML docs are installed - more than enough to > > warrant a -doc package too. > > Ah, so here's the trouble. I did _exactly_ that, but my previous sponsor told me > not to do it, since he felt 500 kb didn't warrant a new package, and that the > dev package is almost useless without the docs. But if you insist, so be it. In practical terms, not all those who need the -dev package are actually writing new software with that -dev. A lot are simply *building* reverse dependencies of that -dev. When someone needs to build pilot-qof, there is no need for them to have libqof-doc, they only need libqof-dev. Such issues also affect the autobuilders - there is no need for them to have the doc content when trying to build a dependency using the -dev. > > With these in place, you can tweak the short descriptions to indicate > > what is contained in each package by only mentioning "C++ library" for > > libitpp6 and adding a suffix of (development files) (debug files) > > (documentation) or something along those lines. Compare with libqof1: > > I would request you to elaborate on this. Do you just mean to explain separation > of packages into docs, dev and dbg? No, tidying up the short descriptions so that the new packages are not simple copies (as the -dev is currently). libqof-dev Query Object Framework - Development Headers libqof-doc Query Object Framework - API Documentation libqof1 Query Object Framework libitpp-dev - signal processing and communication - development files libitpp-doc - signal processing and communication - API documentation libittp-dbg - signal processing and communication - debug symbols libitpp6 - C++ library for signal processing and communication debtags are useful too but a lot of people still limit their searches to apt-cache search so it is best to make short descriptions unique. > > This package has a large dependency tree (127MB of archives). Libraries > > are difficult enough without adding so many dependencies. > > I was unaware of the fact that atlas suffered from so many deficiencies. ? You should always build your own packages with pbuilder at least once for each upstream release - if only to ensure you have the Build-Depends right. Simply watching or reading the pdebuild log will show you that your package brings in more packages than a relatively large GUI application. Please look beyond your own package and try to anticipate problems. > However, I guess I can drop dependency on atlas (see > http://itpp.sourceforge.net/index.php?wiki=About ), though I'd consult upstream > before doing that. Yes, the reduced functionality is a concern. Upstream may be able to separate the codebase so that you can create a libitpp-atlas6 and libittp6 that would be without atlas - one conflicting and replacing the other (not ideal) or one complementing the other by adding new files without replacing libittp6 (harder to do upstream). It's not something to do now (unless upstream already make it easy to do) but ensure that you subscribe to atlas via the PTS so that you are kept updated with the status of it's RC bug(s) and general health. Just put your email address into the subscribe box at: http://packages.qa.debian.org/a/atlas3.html Note that according to the PTS, the maintainer of atlas has not made an upload himself since 2005, there are 4 unapplied patches in the BTS (two of which are debconf translations that are normally trivial to apply) and the standards version is out of date. All signs of a maintainer who is more active in other areas as well as a quiet/dead upstream. > > Tell me about yourself - how familiar are you with some of the > > dependencies of this package? > > I am an "end-user" of this package, and not very familiar with the dependencies. > Therefore, I didn't see the storm brewing. Hmm. The New Maintainer Guide does clearly warn about packaging libraries. What is the application that uses libittp? As sponsor I can help with libittp issues and advise on other general issues but you do need to take a lot of this on board yourself and find your own motivation to look beyond the specific package and into the issues that are just waiting to become *your* problems later. > > > > > > The package is lintian clean. > > > > No, it is not. > > > > W: libitpp source: debian-rules-ignores-make-clean-error line 35 > > W: libitpp source: substvar-source-version-is-deprecated libitpp-dev > > Got that. Another template issue - as Nico highlighted, this is a common error. However, the frequency of the error doesn't mitigate the frustration on behalf of the sponsors who discover it. :-( It does look like the mentors template could do with being clearer on just what has to be edited and added to the bare template. In 90% of RFS emails that I have seen on this list, the bare template has been insufficient or inaccurate due, presumably, to the template not making it sufficiently clear which elements must be edited or modified. This is a problem with debhelper too (which is why we have things like lintian in the first place). -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpP72JWNRx9N.pgp
Description: PGP signature