[Aptitude-devel] My first commits to the repository and question about future releases

[Axel Beckert]

Hi,

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
automatically.

> >    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.

Ok.

> I think best bet is an override and moving the man page to
> hypothetical aptitude-common (along with other arch-indep
> files).

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.

Great!

> > 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".

Yep.

JFTR: I applied for group membership, too.

		Regards, Axel
-- 
 ,''`.  |  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