Re: post-release package update policy
> From: Marcus Daniels <marcus@sysc.pdx.edu>
> 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
Reply to: