> From: Marcus Daniels <[EMAIL PROTECTED]> > Subject: Re: post-release package update policy > > I fail to see the point of a release unless `it' is a known, frozen > set of packages. If this isn't feasible (which it appears may well > be the case), then just don't ever make releases.
Yes, suppose Debian 0.93R6 had been frozen as an "official release" last week, as some have wished. The last couple of days of debian-changes tell me that versions of two new packages are available now whose only modification was to include new or improved documentation. Another update for a network package included significant security improvements. I think anyone downloading a release today -- including CD-ROM vendors and new users -- would want a Debian with those new packages, not last week's hypothetical "release," however official. Of course, that assumes that no new problems have inadvertantly been introduced in the new packages; and that is the rub. There seems to be concensus on having a "stable" release available; but we diverge when describing a "stable" system. Does a stable Debian A) have unchanging files, or B) perform the most reliably? Of course both would be best, but we should not expect to get so lucky, despite hard careful work. I am neither a new user of Unix nor a CD-ROM vendor, so I prefer B, the most reliable and powerful Debian. A most excellent feature of Debian is the ability to uninstall something instantly and completely. If I discover a problem with a new package, I can remove it instantly and replace it with the one I was using before; and send a bug report and/or note to debian-users so that others will also be alerted immediately. So I think the risks of an evolving system are minimal if certain easy precautions are taken. The cautious administrator will keep the .deb files of packages he replaces (outdated packages should remain available by ftp for the same reason). Debian package builders and the architects of the package system might do well, additionally, to keep in mind that the cautious administrator will want to preserve his old "configuration files" with his old package. I haven't seen yet if there's a way to quickly determine the list of "configurable files" for a package. A convenient command to archive a snapshot of these files for given packages would be a boon in reducing the risk in updating packages, and would furthermore be independently useful as a tool in the learning process of configuring a package. Sincerely, Matt
