>> > The need for gcc-2.95 usually means the source code is broken (in C99 >> > terms) and should be fixed. Do you have an example of an use case where >> > this is unfeasible, and which is important enough to justify continued >> > maintenance of gcc 2.95? >> >> Device driver development for embedded systems? There are embedded >> systems, including x86-based, that run kernels which fail to compile with >> gcc >= 3.x. > > In that case you likely need as well an older binutils version, which > probably means to use a sarge or even woody chroot.
I have not yet faced a situation where newer binutils wont, work. > >> Also, people have some code (old completed internal projects, etc), which >> probably would never be ported to newer C++ standards (it's plainly too >> big job), but which are still useful to keep working - e.g. for >> demonstration/education/similar purposes. > > AFAICS this makes a point to have some (un-/little) maintained version > of gcc-2.95 somewhere. It doesn't make a point to distribute it as part > of an official etch release. > >> - user who faces old compiler's failure >> to build code should seriously consider switching to newer versions - but >> just keeping packages installable and usable. > > Apparently those packages weren't useful/important enough to bring them > into Debian... Are debian compiler packages intended to compile debian packages only, or also to be used as compiler for non-debian tasks also? The situation is: gcc-2.95 is no longer needed to compile debian packages, but it is still needed for other tasks, by many people. So why remove it? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
