On Tue, 22 Sep 2015, Markus Koschany wrote:
>
> I think we can drop lynx from Build-Depends since it is commented out
> anyway and I would remove Thorsten Werner from Uploaders.
I agree, this important package for the team (and the project) should
have an up-to-date list of Uploaders. I guess Emm
Am 23.09.2015 um 09:53 schrieb Emmanuel Bourg:
> I pushed the java-policy package on Alioth [1], reviews are welcome.
> I'll remove the policy from java-common once the java-policy package is
> in unstable.
I think we can drop lynx from Build-Depends since it is commented out
anyway and I would re
I pushed the java-policy package on Alioth [1], reviews are welcome.
I'll remove the policy from java-common once the java-policy package is
in unstable.
Emmanuel Bourg
[1] http://anonscm.debian.org/cgit/pkg-java/java-policy.git
Am 22.09.2015 um 17:55 schrieb Emmanuel Bourg:
> Le 22/09/2015 17:32, Thorsten Glaser a écrit :
[...]
>> Can’t you get it merged into the normal debian-policy package?
>
> Good question, and that would probably close #395374, but I'm unsure
> about the implications of such a move. Will the Java Te
Le 22/09/2015 13:49, Thorsten Glaser a écrit :
> It’s 56K installed, the overhead is probably too big.
To be exact, it's 172K with the .ps .txt and .xml versions in
/usr/share/doc/java-common, and 260K if you include the FAQ.
Emmanuel Bourg
On Tue, 22 Sep 2015, Emmanuel Bourg wrote:
> > Can’t you get it merged into the normal debian-policy package?
>
> Good question, and that would probably close #395374, but I'm unsure
> about the implications of such a move. Will the Java Team be able to
> easily amend the Java policy if it's tied
Le 22/09/2015 17:32, Thorsten Glaser a écrit :
> Hmm. But in that case you also must split the source package.
> Just saying.
Yes, that's indeed my intent.
> Can’t you get it merged into the normal debian-policy package?
Good question, and that would probably close #395374, but I'm unsure
abou
On Tue, 22 Sep 2015, tony wrote:
> in the archive. We may want to iterate over policy frequently, and do
> so without triggering upgrades for every installed copy of java-common.
Hmm. But in that case you also must split the source package.
Just saying.
Can’t you get it merged into the normal d
Le 22/09/2015 17:13, tony a écrit :
> It would also be nice if the policy package was named something
> obvious, like java-policy. :)
Actually I was thinking about something like
"somewhat-normative-best-practices-collection-for-java-packages", but
your suggestion is shorter :)
Emmanuel
On Tue, Sep 22, 2015 at 04:59:23PM +0200, Emmanuel Bourg wrote:
> Le 22/09/2015 16:44, Markus Koschany a écrit :
>
> > I agree with Thorsten that this would imply a packaging overhead for
> > only a little gain. Although I think that splitting the documentation
> > would be cleaner, it is probably
Le 22/09/2015 16:44, Markus Koschany a écrit :
> I agree with Thorsten that this would imply a packaging overhead for
> only a little gain. Although I think that splitting the documentation
> would be cleaner, it is probably not worth the effort for a few KB. No
> strong preferences from my side t
Am 22.09.2015 um 13:02 schrieb Emmanuel Bourg:
[...]
> What do you think?
I agree with Thorsten that this would imply a packaging overhead for
only a little gain. Although I think that splitting the documentation
would be cleaner, it is probably not worth the effort for a few KB. No
strong prefere
Am 22.09.2015 um 13:02 schrieb Emmanuel Bourg:
> Hi all,
>
> The src:java-common package currently contains:
> - the default-jre/jdk meta packages defining the default Java per
> architecture
> - the update-java-alternatives mechanism
> - the packaging policy for Java packages
> - the Java FAQ
>
>
On Tue, 22 Sep 2015, Emmanuel Bourg wrote:
> What do you think?
It’s 56K installed, the overhead is probably too big.
bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT
Hi all,
The src:java-common package currently contains:
- the default-jre/jdk meta packages defining the default Java per
architecture
- the update-java-alternatives mechanism
- the packaging policy for Java packages
- the Java FAQ
Including the Java policy in java-common is a bit odd, it means J
15 matches
Mail list logo