[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#448286: java-common: [POLICY-PROPOSAL] Almost all Java libraries should be in section libs.



Hi,

number of binary packages is relatively easy if it doesn't need to be precise:

$ aptitude -F '%20p %13s' search '~Djava' | wc -l
419
(all packages depending on packages containing java in their name; a quick browsing through it tells me that it's a rather meaningful list)

Is there a command to get the source package name based on the binary package name (aptitude doesn't seem to know about source packages)? Then it's as easy... (I've got an idea of an ugly apt-cache hack, but perhaps there is better)

What do you mean with "a proposal for archive admins"? Are you referring to some part of the Debian policy I should actually know about? (well, I'm no DD, so I've got an excuse)

Cheers, Eric

Matthias Klose wrote:
Michael Koch writes:
On Sat, Oct 27, 2007 at 10:24:56PM +0200, Eric Lavarde wrote:
Package: java-common
Version: 0.26
Severity: wishlist


Hello,

in section 2.4 "Java libraries" it should be specified that packages
containing such libraries should belong to the 'libs' section and not
to the 'devel' section.

As Java libraries, to the difference of C libraries, are at the same time for runtime and development usage, they could be in both,
but as 85% of them are already in this section, it makes more sense to
make it consistent this way. Also, a java developer should know this,
where a java user might not expect libraries to be in devel.
Agreed.

It would be better create an special 'java' section (as perl and python
have there own sections too) but thats another issue.

afaics this needs some data (# of source packages for the new section,
# of binary packages for the new section), then a proposal for archive
admins.

please could somebody provide this information / package lists and
post it to debian-java?

I don't like having to change package sections twice.

  Matthias


Attachment: depends_on_java.txt.gz
Description: GNU Zip compressed data


Reply to: