http://www.lojadotelemovel.com/images/riscado_cinza.gif";>
http://www.lojadotelemovel.com/mailing/images/logo.jpg";
width="580" height="49">
http://www.lojadotelemovel.com/mailing/images/topo.jpg"; width="580"
height="93">
On Mon, 13 May 2002 07:47:35 +0100
Julian Gilbey <[EMAIL PROTECTED]> wrote:
> > Sounds better than my patch, and it seems to convey much of the information
> > that I tried to convey.
>
> Although sometimes this is not correct, for example if multiple
> co-operating packages use the same /usr/lib
> "Andrew" == Andrew Pimlott <[EMAIL PROTECTED]> writes:
Andrew> seems to forbid both code with native parts, and Java code
Andrew> compiled to machine binaries with gcj. It seems reasonable to
Andrew> me to allow both of these.
Does this really need to be part of the java policy? I thought
On Sat, May 11, 2002 at 11:17:04AM +0900, Junichi Uekawa wrote:
> Steve Greenland <[EMAIL PROTECTED]> immo vero scripsit:
>
> > > How about simply:
> > >
> > > If your package includes run-time support programs that don't need to
> > > be invoked manually by the users, or named in a way that
On Mon, May 13, 2002 at 10:42:02AM -0500, Manoj Srivastava wrote:
> >>"Anthony" == Anthony Towns writes:
> Anthony> There is _absolutely_ no call for other packaging tools, and
> Anthony> absolutely _no_ need for a standard to make this easy or
> Yeah, right. There is never any need for co
>>"Anthony" == Anthony Towns writes:
Anthony> Julian, please note the above: this is "who's talking about
Anthony> dpkg anyway".
This is getting no where fast.
Anthony> There is _absolutely_ no call for other packaging tools, and
Anthony> absolutely _no_ need for a standard to make
On Mon, May 13, 2002 at 01:45:33AM -0500, Manoj Srivastava wrote:
> >>"Anthony" == Anthony Towns writes:
> >> *Sigh*. Let me see if I can dot the i's and cross the t's. A
> >> package should be buildable using the bits mentioned in policy. Any
> >> package may, however, choose to add any extra
On Mon, May 13, 2002 at 01:29:59AM -0500, Manoj Srivastava wrote:
> >>"Anthony" == Anthony Towns writes:
> Anthony> The documentation should be found wherever the dpkg
> Anthony> maintainers want it, not wherever the -policy maintainers
> Anthony> think might be fun.
> What policy contai
Jim Pick wrote:
>
> Because the set of Java APIs is so large, trying to develop a set of
> class libraries that works as a drop in replacement for Sun's libraries
> is a very large task. In reality, it's going to be a long time before
> the free java class library projects manage to reimplement 1
On Sun, May 12, 2002 at 09:15:31PM -0700, Jim Pick wrote:
> I think the Debian Java policy, as currently stated, is slightly flawed,
> as it tries to satisfy two goals that aren't completely orthogonal:
>
> 1) To get as much free Java software into Debian as possible, that runs
> without non-
>>"Anthony" == Anthony Towns writes:
Anthony> On Mon, May 06, 2002 at 05:19:09PM -0500, Manoj Srivastava wrote:
>> >>"Anthony" == Anthony Towns writes:
Anthony> The real question is whether maintainers are meant to build
Anthony> using the features of dpkg, or the ones listed in
>> *Sigh*.
>>"Anthony" == Anthony Towns writes:
Anthony> The documentation should be found wherever the dpkg
Anthony> maintainers want it, not wherever the -policy maintainers
Anthony> think might be fun.
What policy contains won't be documentation. It shall be a
standard interface that must be
On Sun, May 12, 2002 at 06:22:30PM -0700, Jim Pick wrote:
> Sounds like Debian could use the same solution for gcj that Debian uses
> for emacs -> just distribute the .java files and do the ahead-of-time
> compilation (.java to .so) at install time. Is this automatic enough
> under gcj so that thi
On Monday 13 May 2002 03:22, Jim Pick wrote:
> Sounds like Debian could use the same solution for gcj that Debian uses
> for emacs -> just distribute the .java files and do the ahead-of-time
> compilation (.java to .so) at install time. Is this automatic enough
> under gcj so that this could that
14 matches
Mail list logo
