the setrlimit changes in glibc 2.1.3

[Joel Klecker]

At 14:40 -0500 2000-01-13, Roland McGrath wrote:
>So I think the real question here is, what warranted this kind of change in
>a "bug-fix" release?  I think folks around here have gotten pretty unclear
>on the concept of maintenance releases, and everybody's playing fast and
>loose.
>This is just not the way to operate.  That's why we have a development
>branch, for pete's sake.  Are we going to have to add another level of ".x"
>to the versions to get a truly conservative maintenance release branch?

<AOL/> What the hell kinda release management is this?

I don't trust any of the new rlimit or LFS stuff, so I'm avoiding it in Debian.

Stable releases should never have anything but bug fixes, except perhaps
allowing new features in things besides libc and the dynamic linker
themselves, e.g. nscd or the libthread_db library.

>And, Mark: I'm afraid the realities of packaging systems (and of humans)
>make it hopelessly unwise to attempt to have "the right thing" for anyone
>be to upgrade their shared libraries differently than they upgrade their
>development environment.

I have to agree with that. /usr/<cpu>-linux-gnulibc{2.1,2.1.1,2.1.2} is not
my idea of a good thing.
-- 
Joel Klecker (aka Espy)       <URL: mailto:espy@debian.org >
Debian Package Maintainer for the GNU C Library.