On Sat, 24 Jun 2000, Josip Rodin wrote: > On Sat, Jun 24, 2000 at 01:36:27AM -0600, Barak Pearlmutter wrote: > > > > If i386 smail isn't included when potato releases, literally millions of > > > > boxes will be rather forcibly transitioned to a new MTA. > > > > > > No, they won't, they'll be left untouched. Or is there some kind of bug? > > > > Good point, except ... if it doesn't have some kind of bug shouldn't > > it be included? > > It had some serious bug, that's why it was removed.
While this may be the case sometimes, it's not always so. transproxy was removed during the first round because of a typo in the init.d script - I pleaded with Dark to let me take it over, but to no avail. Now, I've got a production environment that will upgrade to potato, but will have the old transproxy until I build a package, set up a local apt source, and so on. This isn't tough, but it's beyond some of the admins I know. It's also a PITA. Furthermore, now I have an old binary on my box. Will it work with potato's libc? Maybe - maybe not. If it doesn't, then we have, in essence, created bugs by not removing it. I went through this same crap with Debian 1.3 to 2.0 upgrades - bit-rotted packages, but you don't know that they're old because there's nothing to upgrade them too. I propose that packages be assigned to QA (or somewhere) before they fall off the face of the earth for RC bugs (especially like those in this case - a typo in a script, or in the case of smail, for a segv while running from inetd (who runs their MTA from inetd?) that can't be reproduced by the maintainer). Anyway, as Josip says, it's too late for this go-around, but in the future it would be nice to prevent this "skipping generations" thing that occurs now where a package is in slink, not in potato, but in woody because of stuff like this. [EMAIL PROTECTED] | Under deadline pressure for the next week. http://www.debian.org | If you want something, it can wait. | Unless it's blind screaming paroxysmally hedonistic...
