Hrvoje Niksic <hniksic(a)srce.hr&gt; writes: Just so you know: They just froze again. This is weird. The freeze is there to make sure ONLY bugfixes come in. Maybe the problem is that bugfixes in this case seems to be defined more narrowly as "fixes for things as reported in the Debian bug databsse". (Note that [possible due to your complaints] their stable version does contain 1.4.5. The frozen version contains 1.5.3. The recent SUSE 5.3 for instance ships with 1.5.2) So it does for me (it broke more than half of our exercise sets), so I reverted it back again in our group setup. Thank god for symlinks. However it still another case where there is a difference of opinion about a design decision between the package author and our users/sysadmins. In this case our sysadmins decided (rightly or wrongly) to change this in our local version (in this case by reverting to the old version). I think that the world is full of these local hacks by sysadmins and that phenomenon of Linux distributions is just increasing this to another level. Yes. In particular the distribution-freeze method has severe problems when the author also does freeze cycles. For instance Debian 2.1 will still ship with 20.4. In this case this is not such a problem as 21.0 is too major a change to just follow. But imagine if this were a 21.0-21.1 thing and we release 21.1 just after the freeze. What should be happening is that the distribution is tracking our bug fix betas in their unstable branch, i.e. their freeze equals our freeze. Also the term "bugfix" is very vague: The reading of stdin I reimplemented in gnuclient recently, was that a new feature of a bug fix? I have long been intending to write something up for this to sent to Debian (and maybe others) "officially", but have not got arround to this. Jan