On Mon, 31 Jan 2005, Steve Langasek wrote: > Package: gettext > Version: 0.14.1-8 > Severity: important > > Hi Santiago, > > The current gettext package's dependency on libgcj4 was thrust into the > limelight this weekend when it helped create a circular (build-)dep chain > that caused gcc-3.3 to fail to build from source. The gcc-3.3 end of things > was relaxed to let this package build again, but we still have the other end > of the chain, which is: > > debhelper -> po-debconf -> gettext -> libgcj4 > > This means that, to install a tool whose use is so widespread in building > that it has recently been proposed as a candidate for build-essential, > buildds (and developers) must now install libgcj4 and all the packages that > come with it. I think this is a bad thing even when it doesn't cause build > failures, and I think there needs to be a gettext package that po-debconf > can depend on which doesn't drag in this added dependency.
This has been reported before. Could you please read the logs for Bug#291913 and comment on them? [ Most of the rationale for the dependency is explained there ]. Now for the "this is a bad thing" part: If libgcj4 were an order of magniture bigger than gettext, we would naturally worry, but gettext is already 4.7MB large and libgcj4 is just 8MB large (the packages that come with it are small in comparison). I believe the dependency it's not as bad, and considering that it's required to fix a bug, we should accept it as is. > I don't know whether this should mean an expanded gettext-base that > po-debconf can depend on instead of gettext, or an added gettext-java > package that splits off the Java parts (I suspect the latter would be best), > but I think the current situation is definitely suboptimal. What I could do would be to stop using gcj as a native compiler, but then I would need to depend on a java virtual machine. Otherwise Bug#244215 would remain unfixed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
