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

Re: Which JVM can I use?

On Thu, 29 Apr 1999, Thomas Adams wrote:

> On Thu, Apr 29, 1999 at 05:15:16PM +0200, Christian T. Steigies wrote:
> > Just try it out, I think it should work. We still have the same glibc in
> > potato, the same libstdc++, the same whatever. I guess it works on m68k.
> Oh, slink and potato use the same libraries? I thought it was like in Intel
> slink and potato. Yes, it could work then.
We do not use glibc2.1 yet. We do not you egcc as standard C compiler yet.
> A "broken" entry in dselect's list of packages. No big deal, but I hate it.
dpkg --purge <broken_packe>
What will be left after that?
I dont see any other option than you trying that out. Well, I could, but I
dont even know what kaffe is good for. Java? Whats that?
> I really didn't know that there are few people building m68k packages. But
> how does this work? They have a program, make a deb and decide it depends on
> this and that, although neither this nor that are available as a deb file?
There are ~1500 or more packages in debian. Every package has one (debian)
maintainer. They package up the source and decide what it depends upon,
besides the dependencies which are introduced during the build (glibc,
libstdc++, etc). They build the source package and usually a binary package,
for i386, sometimes for sparc or alpha, rarely for m68k. The porters (for
all other arches) pick up the source package and build the binary, if it
builds.  Now I would say there are about 5 active m68k porters, that makes
300 packages per capita. You want to test 300 packages thoroughly?
I install the packages I am personly interested in and/or which are vital for
debian and see if they work. It does happen that there are packages which
compiled fine, showed nothing unusual during build but they still do not
work, ie because it depends on something which is not (yet) available for
m68k, because it makes only sense together with something which we do not
have (netscape addons, music server for quake). When I actually install
them, I might notice that, but this takes quite a lot of time. Time which
not everybody has. Time we are spending on tracing down bugs in so many
packages, hacking on the kernel and building a distribution. Time which many
users seem to have, since they are writing so much stuff on so many mailing
lists. And no, to test a package and file a bug report no programming
knowledge is needed, so thats no excuse this time.
No offense ment, but sometimes I am really asking myself why am I doing
this. You have problems compiling a package which results in a 800k deb?
Well, I have problems building xfree which needs 1.5GB harddiskspace to
build... now guess what I consider more important?


Reply to: