Matt Zimmerman writes: > On Mon, Sep 22, 2003 at 09:24:44AM +0200, Matthias Klose wrote: > > > tags 212085 + wontfix > > thanks > > > > Matt Zimmerman writes: > > > Package: gcc-3.0 > > > Version: 1:3.0.4ds3-16 (not installed) > > > Severity: serious > > > > > > Build-Depends: libc6.1-dev (>= 2.2.5-6) | libc6-dev (>= 2.2.5-6) | > > > libc0.3-dev, libc6.1-dev (<< 2.3) | libc6-dev (<< 2.3) | libc0.3-dev (<< > > > 2.3), m4, autoconf2.13, libtool, gawk, dejagnu (>= 1.4), bzip2, binutils > > > (>= 2.12.90), debhelper (>= 3.0.25), gperf (>= 2.7-3), bison, flex, > > > gettext, texinfo, zlib1g-dev, libgcc1 > > > > > > and libc6-dev, of course, is past version 2.3 now. > > > > libstdc++3 does not build on glibc-2.3 based systems, so the build > > dependencies are correct. I don't know of any patch. > > > > IMO the shared library should still be included in sarge to satisfy > > the needs of third party packages, and to serve as an compiler > > alternative on hppa (as does gcc-2.95/gcc-2.96 do on other archs). > > > > I propose to close this report or tag it as sarge-ignore (but I > > suppose I'm not allowed to do the latter). > > It is a problem for us to ship binary packages that we cannot build.
We did it before shipping unbuildable libstdc++ packages (built from egcs-1.x), and I assume we are able to find other examples. we still can build it from source on a (current) stable system. > What happens if we needed to do an urgent update on this package > (e.g., security)? Or if a user needs to patch and rebuild it? show me even one security update for a gcc package in the last years. give me a reason why a user should rebuild a runtime library. I don't argue that your reasons are invalid, but they are unlikely enough that it's worth to consider keeping the package in sarge. Matthias