Package: debbugs
Severity: wishlist

[01:12:52] Tincho: what exactly are you trying to do?
[01:13:18] dondelelcaro: I maintain the scripts that build this
page: http://pkg-perl.alioth.debian.org/cgi-bin/qareport.cgi
[01:13:52] for that, I construct a list of source packages I'm
interested in, and then call get_bugs(src => \@list)
[01:14:28] then, for retrieving the status of each bug,
get_status(@list_of_bugs)
[01:14:57] oh, and you just want to know which bugs were
retunred by which source package
[01:15:04] dondelelcaro: exactly

There are two things that could be done: adding a "source" key to the
hash returned by get_status, or enabling get_bugs to return a hash
indexed on the requested source package. The latter seems easier to
implement, although it would mean that I still have to make many
queries; the former would be ideal for me: two queries would return all
the information I need.

Russ Allbery wrote:

There's some room for clarification here.

I think it is apparent from comments given in 2001 the that the policy
wish-bug under debate concerns the _binary_ package name, and not the
_source_ package name. The Debian policy however isn't entirely clear on
whether it intends to mandate the source or binary package name or both.
Let me repeat its current text:

| 4.2 Module Package Names
|
| Perl module packages should be named for the primary module provided.
| The naming convention for module Foo::Bar is libfoo-bar-perl. Packages
| which include multiple modules may additionally include provides for
| those modules using the same convention.

I dont see a benefit in this at all. It just adds confusion for the sake
of "short package names". Especially as you shouldnt (build)-depend on
virtual packages, so those would need to use the shorter names
too. Having the direct "x::y is libx-y-perl" is IMO more important than
less to type in.

=2D-=20
bye Joerg
http://meta.wikimedia.org/wiki/How_to_win_an_argument

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

On Wed, 02 Jan 2008 00:58:12 -0200, Martín Ferrari wrote:

Count me in -- I appreciate the simple mapping of Foo::Bar to
libfoo-bar-perl, too.

Ack.

But I don't oppose to the policy change, as long as the "fancy" names
are optional and the "real" names are required to be in a Provides
field (and that's the way I read the proposal).

Package: libxml-xpath-perl
Version: 1.13-6
Severity: important

It looks like the libxml-xpath-perl package should be phased out and
eventually get removed from Debian. The module is unmaintained upstream
(last release was in 2003), and there's a maintained, faster and less
buggy alternative available in libxml-libxml-perl.

The codebase in XML::XPath has also been forked upstream into
XML::XPathEngine with a different API. The libxml-xpathengine-perl
package entered Debian in late 2007.

See also the perl-xml thread starting at

http://aspn.activestate.com/ASPN/Mail/Message/perl-xml/3438368

I do plan to get the Debian package in a better state now that we're
adopting it for the pkg-perl group. Still, I think the best solution
in the long run would be to get it removed, as fixing eg. #315628 is on
the borderline of diverging the API from upstream.

The reverse dependencies of libxml-xpath-perl are currently

I think it's better to Debian Perl adopt it, because no updates for a very long
time.

If Florian wants to touch it, he should be a member of Debian Perl.

--
Marco Rodrigues

http://Marco.Tondela.org

Hi Gunnar,

while you were away for the holidays, I took the freedom to commit
your patch to DebianQA, plus the small modifications I added to it. I
also modified qareport to show the short description after the package
name, and everything seems to be working nicely.

$ ./qareport -c /srv/home/groups/pkg-perl/.debianqa/qa.conf
Showing 110 out of 597 packages
dh-make-perl: Create Debian packages from perl modules
- Problems: has_bugs
- Repository status: OK
(...)

Now somebody has to write the template modifications :)
I was thinking in just making a "expand" button which would show a big
box with all the available info (retrieved by other ajax-y script)