Re: post-release package update policy
On 26 Oct 1995, Kai Henningsen wrote:
> dwarf@symnet.net (Dale Scheetz) wrote on 25.10.95 in <[🔎] 9510251914.AA12174@symnet.net>:
>
> [...]
> > Product is. While trying to build a system, dpkg changed enough to loose
> > it's old database (rather than provide a conversion) and "forgot" that it
> > had installed the base package. When I went to remidy that problem, the only
> [...]
>
> That's a bad experience all right, but I just don't see how having a non-
> changing release would have avoided it.
Well, I do! It would have given me the opportunity to fall back to the
"release" package anytime I install an updated package that, for one
reason or another, fails to opperate to my liking.
*************************************************************************
The rest of this is a bit long but please bear with me...
There are two major concepts that have become interwoven in this
discussion fairly tightly. I would like to see them come untangled and
followed as two threads. One is the issue of what constitutes a release.
The other is the issue of what files to maintain on the FTP site and how
to organize them.
As a user and as a developer, I would argue that what constitutes a
release and when to declare them should remain completely in the hands of
the developers. They are the ones with the vision, goals and global
understanding of the system. They look for the best available material,
set targets for project completion and, of course, implement those
projects to produce the next level of software. Let them decide when a
release is ready. (and don't forget to thank them for their wonderful
effort!)
For the other issue, lets, just for the sake of argument, say that today
is the release day. (I just happen to have a directory of the net
packages directory that was taken today)
The net directory looks like:
-rw-rw-r-- 1 10000 debian 133181 Sep 16 23:33 amd-upl102-1.deb
-rw-rw-r-- 1 10000 debian 350483 Aug 6 03:17 bind-4.9.3-BETA24-1.deb
-rw-rw-r-- 1 10000 debian 177646 Aug 23 13:31 cern-httpd-3.0-4.deb
-rw-rw-r-- 1 10000 debian 61963 Oct 9 15:27 diald-0.10-2.deb
-rw-rw-r-- 1 10000 debian 529506 May 12 00:47 ircii-2.8.2-1.deb
-rw-rw-r-- 1 10000 debian 51521 May 13 05:29 lpr-5.9-6.deb
-rw-rw-r-- 1 10000 debian 189477 Sep 30 23:23 lynx-2.4.2-1.deb
-rw-rw-r-- 1 10000 debian 172297 Oct 25 13:39 netbase-1.20-1.deb
-rw-rw-r-- 1 10000 debian 648213 Oct 25 13:39 netstd-1.21-1.deb
-rw-rw-r-- 1 10000 debian 79060 Oct 6 03:58 ppp-2.2-1.deb
-rw-rw-r-- 1 10000 debian 372851 Sep 27 19:40 samba-1.9.14-1.deb
-rw-rw-r-- 1 10000 debian 330003 Jul 16 19:39 snmp-2.1.2l3-1.deb
-rw-rw-r-- 1 10000 debian 78374 Jul 18 14:40 tcpdump-3.0.3-3.deb
-rw-rw-r-- 1 10000 debian 630022 Oct 17 14:56 w3-el-2.2.22-1.deb
-rw-rw-r-- 1 10000 debian 59597 Oct 17 14:56 wu-ftpd-2.4-14.deb
-rw-rw-r-- 1 10000 debian 273869 Sep 30 23:23 xntp-3.4x-1.deb
-rw-rw-r-- 1 10000 debian 28201 Sep 5 14:02 ytalk-3.0.2-1.deb
>From this point on, all of these files will be available here until
the next release, but tomorrow there is a new ppp package...no problem.
Tomorrow the directory might look like this:
-rw-rw-r-- 1 10000 debian 133181 Sep 16 23:33 amd-upl102-1.deb
-rw-rw-r-- 1 10000 debian 350483 Aug 6 03:17 bind-4.9.3-BETA24-1.deb
-rw-rw-r-- 1 10000 debian 177646 Aug 23 13:31 cern-httpd-3.0-4.deb
-rw-rw-r-- 1 10000 debian 61963 Oct 9 15:27 diald-0.10-2.deb
-rw-rw-r-- 1 10000 debian 529506 May 12 00:47 ircii-2.8.2-1.deb
-rw-rw-r-- 1 10000 debian 51521 May 13 05:29 lpr-5.9-6.deb
-rw-rw-r-- 1 10000 debian 189477 Sep 30 23:23 lynx-2.4.2-1.deb
-rw-rw-r-- 1 10000 debian 172297 Oct 25 13:39 netbase-1.20-1.deb
-rw-rw-r-- 1 10000 debian 648213 Oct 25 13:39 netstd-1.21-1.deb
-rw-rw-r-- 1 10000 debian 79060 Oct 6 03:58 ppp-2.2-1.deb
-rw-rw-r-- 1 10000 debian 96145 Oct 27 06:45 ppp-2.3-1.deb
-rw-rw-r-- 1 10000 debian 372851 Sep 27 19:40 samba-1.9.14-1.deb
-rw-rw-r-- 1 10000 debian 330003 Jul 16 19:39 snmp-2.1.2l3-1.deb
-rw-rw-r-- 1 10000 debian 78374 Jul 18 14:40 tcpdump-3.0.3-3.deb
-rw-rw-r-- 1 10000 debian 630022 Oct 17 14:56 w3-el-2.2.22-1.deb
-rw-rw-r-- 1 10000 debian 59597 Oct 17 14:56 wu-ftpd-2.4-14.deb
-rw-rw-r-- 1 10000 debian 273869 Sep 30 23:23 xntp-3.4x-1.deb
-rw-rw-r-- 1 10000 debian 28201 Sep 5 14:02 ytalk-3.0.2-1.deb
As additional upgrades come in they get plumped down here. When a second
upgrade has been made to a particular package, it becomes time to decide
if the first upgrade can be deleted. I would argue that it can be deleted
when there is satisfaction that upgrade 2 introduces no new bugs and
"works as well as" the previous upgrade.
Under this scheme the files themselves help the user make the decission
about time to upgrade as well as providing a fall back to a less unstable
(hopefully) package than the bleeding edge.
If a package moves from one directory to another, it's most previous
release and lates upgrade should remain in the old directory (to avoid
confusion and the need to hunt). It would be sufficient for these to be
links and not files. (if I understand what the mirror site folks are
saying this should pose no problems, and maybe make the whole process
easier!)
I don't see any need for complex directory structures to keep things
seperate. The version numbering scheme does that quite well all by
itself. You know right off what has been upgraded and roughly how stable
it is. When it comes time to announce a new release, every package below
the latest version gets removed and the new set of files become the
starting point for the new release. (Backing up the old release on
another directory path is of course optional, provided there is
sufficient disk space)
Thanks for your time,
Dale
Reply to: