[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: