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

Re: Which JVM can I use?



Christian T. Steigies wrote:
> > 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?

I suggest you read the Developers Reference if you are interested how the
Debian project works. The existence of packages in the distribution that
depend
on nonexisting packages is a result of the i386 centric nature of Debian. 
The contents of the distribution is defined by the i386 arch, with
nonexisting
packages excluded or dependencies and install profiles redefined manually
on other ports. Any of these manual steps may have been overlooked in the
final 
week(s) before release. I don't recall ever seeing error messages about
guavac
depending on a JVM which doesn't exist, and I don't recall the slink-CD 
maintainer ever complaining about this either. guavac doesn't depend on
anything but libc and libstdc++, so I guess that was OK. The error would 
be on part of the guavac maintainer. 

> 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'd say we rely on the i386 guys testing the packages :-) and focus on
building
m68k packages. I count about 3 active m68k porters, and with the automatic
build machine broken that's going to be hard enough (_without_ running
into 
trouble with packages not building out of the box). 

With the current glibc 2.1 situation, things will get _really_
interesting.

	Michael


Reply to: