severity 292988 wishlist reassign 292988 debhelper retitle 292988 debhelper: please try not to depend on po-debconf thanks
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. This was completely gcc-3.3's fault. Blaming gettext's dependency on libgcj4 for it is not only unfair, but highly unaccurate. It would be like saying that "apt-get's handling of dependencies helped to create a circular dependency chain" as an argument to ask APT author that apt-get should not follow dependencies strictly. As I said to Matthias Klose, the dependency on libgcj4 is natural in the sense that it comes directly from running dpkg-shlibdeps on the executables, so I can't accept that it "gives buildds the hives". IMHO, what the circular (build-)dep chain thrusted into the limelight was how risky and dangerous is to use very tight ">=" dependencies in combination with architecture-independent packages which depend on architecture-dependent packages or viceversa. In the case of gcc-3.3, there are architecture-independent packages which depend on architecture-dependent packages, which means they propagate to the other architectures instantly, so one has to be careful about their >= dependencies. I have not analyzed the gcc-3.3 case in detail, but I think an acceptable workaround for this would be to switch some of the architecture independent packages from Arch: all to Arch: any, even if they do not contain architecture specific content. This way they would not propagate instantly to other architectures, and they would only enforce a stricter ">=" dependency on a given architecture *after* the source has been successfully compiled for such architecture. I'm Cc:ing Matthias in the hope that he considers this idea. > 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 > > [ snipped paragraph which talks about how bad this is ] Ok, this is my analysis of the above chain: Yes, I agree it's not nice (but not to the point of suggesting that the old gettext package comes back). Let's see: The first "big" package in the chain is gettext, which is already 4.7MB large. Clearly, po-debconf should depend on it or in a similar package, since that's its main purpose. The dependency of gettext on libgcj4 comes from dpkg-shlibdeps. What's left? The dependencty of debhelper on po-debconf. Such dependency was added in October 2002, but at that time, gettext was *already* quite big. Considering that not everybody who uses debhelper uses po-debconf, the logical thing to do here, IMHO, to preserve granularity, would have been not to add such dependency, but instead require that packages which need po-debconf (a minority of them) add it to their build-depends. Adding an indirect dependency on gettext, which was already big in 2002, and then complaining that gettext becomes even bigger does not make much sense. In either case, all these tools, debhelper, po-debconf, gettext are development packages and we developers and autobuilders can deal with them without problems. This is not even the size of TeX or GNOME. We would be *really* breaking granularity if we made a "user" package to gratuitously depend on a "development" package, like for example, making the base systen to depend on unwanted -dev packages, but this has not happened in gettext. The gettext-base package, which is installed by default, has now a file called libintl.jar. This file is 2311 bytes long and the dependencies of gettext-base have not changed. Sure, libgcj4 is very big, but that's not a bug, it's a feature, and it's not something we should be ashamed of. If we are seriously going to promote java as a programming language, we should not consider a "Depends: libgcj4" on a development package as a bug, much less of important severity. > [ snipped additional paragraph suggesting packaging changes in gettext ] So this was a suggestion to create an additional package, then. I would have made this report to look closer to an ITP, which means severity: wishlist. Anyway, to summarize: No, I don't think there is a need to create additional packages. The old gettext package should not come back, as it had bugs which are now fixed. Creating a gettext package "only for autobuilders" would be an ugly hack. The current gettext package follows quite closely the recommendations given by the PACKAGING document in the source code. Deviating from this would not be good. I'm reassigning this report to debhelper in case Joey wants to reconsider the dependency of debhelper on po-debconf. We might need a transition period or something alike. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
