[Aptitude-devel] My first commits to the repository and question about future releases
abe at debian.org
Mon Jan 16 16:59:08 UTC 2012
Daniel Hartwig wrote:
> > Source package:
> > W ancient-standards-version
> > 3.8.3 (current is 3.9.2)
> > -> Should be updated. Check one of
> > /usr/share/doc/debian-policy/upgrading-checklist.*
> Bump to 3.9.1 is ok IMO. With 3.9.2 there is:
> > 3.3
> > The maintainer address must accept mail from Debian role accounts
> > and the BTS. At least one human must be listed with their
> > personal email address in Uploaders if the maintainer is a shared
> > email address. The duties of a maintainer are also clearer.
> Is this an issue given that the current maintainer address is not
> responsive for some time?
No. AFAIK this was introduced because there were some packages which
just had a mailing list set as maintainers and it wasn't obvious which
persons are responsible for the package.
But I'd think about setting the maintainer address to
aptitude-devel at lists.alioth.debian.org and moving Daniel Burrows to
Uploaders. That way all future bug reports would go to the list
> > E python-script-but-no-python-dep
> > usr/share/bug/aptitude
> > -> If reportbug (which makes use of that script) is installed, python
> > will be installed anyway, so I'd override this lintian warning and maybe
> > even file a bug against lintian.
> Converted this to sh as the interface is well-defined and it is
> conceivable that some package other than reportbug may make use
> of the script. The original was trivial enough to not justify
> use of python anyway.
That's fine, too.
> > W binary-without-manpage
> > usr/bin/aptitude-curses
> > -> No problem, but I think either a slave alternative to aptitude or a
> > lintian override should be added. I'd prefer the slave alternative.
> > aptitude-gtk
> > W binary-without-manpage
> > usr/bin/aptitude-gtk
> > -> See above.
> I did consider a slave alternative though don't think it is
> suitable at the moment since there is no dedicated man page
> describing the GTK-standard options.
> I think best bet is an override and moving the man page to
> hypothetical aptitude-common (along with other arch-indep
Sounds ok until someone writes an aptitude-gtk man page.
> > W debian-rules-missing-recommended-target
> > build-arch
> > build-indep
> > W package-would-benefit-from-build-arch-targets
> > -> Hopefully not too complex to add.
> There is a patch with empty targets but I didn't think
> that would be very useful.
Agreed, especially because of
"package-would-benefit-from-build-arch-targets". That's why I didn't
write "trivial to fix". ;-)
> With a little more effort we can at least move the docs to
> build-indep and get some actual benefits.
> > I arch-dep-package-has-big-usr-share
> > 7336kB 66%
> > -> Maybe not easy. I'd say not top priority, but worth to look at.
> Yes -- certainly enough there to justify "aptitude-common".
JFTR: I applied for group membership, too.
,''`. | Axel Beckert <abe at debian.org>, http://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
`- | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
More information about the Aptitude-devel