Re: Special upgrade rules from rex->bo->hamm

[Jason Gunthorpe <jgg@gpu.srv.ualberta.ca>]

On 27 Jan 1998 bruce@va.debian.org wrote:

> > If we put conflicts and depends
> > lines on it then it will be able to manipulate the package state simply by
> > installing it. Automatic removal and installation will occur just as if it
> > were a normal package.
> 
> I don't think you can use dependencies and conflicts for this.
> We want it to upgrade only _selected_ packages and their dependencies.

It depends exactly what you want :\
 
> If magic packages work for the users but the developers have to push a
> button, it sounds like a win to me. Put a control file field in the
> package called "Deity-Special-Debian-Version: 2.0". When this is seen,
> it's compared with the same field in the installed version. If the new
> one is greater, you get the dialogue asking if you want to upgrade. Say
> yes, and it's the same effect as if you were pushing the upgrade button.
> This package would be put in a release just at the time that it becomes
> stable. While it is unstable, the archive would not contain the magic
> package and you would not get the prompt.

I have been thinking about this and I would much rather have a second
file. Consider a file with the name 'Revision'[1] stored in the same place
as the packages file. This Revision file would play an important role in
the whole system.
  1 - It would serve as a name for all of the Package Versions. For
      instance when you ask for a list of available versions you might see
     Debian 1.3.1r6 (1.2-10)
     Debian 1.3 (1.2-6)
     Debian Unstable (1.3-1)
     Fuller (1.3-f1)
  2 - When the primary Revision changes (unstable->frozen->stable) the
      user will be prompted to all-upgrade immediately.
  3 - It will serve as a permanent unique tag on all distribution media of
      what the package versions are to be called. (CD-ROM)

This is simpler to deal with than a field buried in the packages file and
is a little more intuitive for the user looking at the FTP archive or CD.

I would like to discuss the implications of Behan's multiple source
requirments and how my choice of implementation is going to play a role in
this.. I am working on the details right now so this is a bit ruff :>

First let me explain the significance of my example above.

   Debian 1.3.1r6 - This packages file was retrieved from a FTP mirror
                    and is the latest and greatest
   Debian 1.3     - This was retrieved off a users older Debian CD. The CD
                    is still availble for installation of packages! This
                    means if a package is installed (but hasn't changed)
                    it does not have to be downloaded
   Debian Unstable - This is also from the FTP mirror (unstable dir
                     naturaly)
   Fuller - This is from a 3rd party distribution unrelated to debian,
            notice the -f before the debian revision to give uniqueness.

Now, lets consider the same system in a few months, under normal
operation, with the user having selected to FTP stable and unstable and
having purchased two hamm cds, we would have:
   Debian 1.3    - The old CD is not removed! [2]
   Debian 2.0    - Hamm CD
   Debian 2.0r5  - A newer hamm CD
   Debian 2.0r10 - The FTP site
   Debian pre2.1 - The frozen unstable distribution

All of the above would be avaiable to the user as possible sources of
versions. Naturally most of this will be hidden, the user will have a
default distribution [stable] and Deity will figure out the
quickest way to get the packages, either through a CD or a download.
Advanced users will be able to upgrade specific packages to specific
distributions.

The revision file might have a format like this:

<tag> <Revision name>

Where Tag is one of stable or unstable. Revision name is the text shown
above. So right now we have
stable Debian 1.3.1r6
unstable Debian Unstable

and in a few months 'unstable Debian Unstable' will be converted to
unstable Debian pre2.0

and in a few more months it will become
stable Debian 2.0

Please notice I have not included 'frozen' as a possible distribution tag.
This is because the frozen only exists for a tiny fraction of time and
should not confuse the user. The user will select if they wish to follow
the newest stable version or the newest unstable version.

There are still a number of unanswered questions with this, for instance
how is bo-updates, projects/experimental, and Incoming handled and how
will the stable/unstable tags relate to 3rd party dists.

I hope you all see some of the issues I am having with the whole naming
system :> Hopefully in a few more days I can be a bit more complete.

Thanks,
Jason

1 - Revision is a bad term, I'm not that fond of it.
2 - It is not very easy to purge the old CD's from the system
automatically, I have a hard time thinking of how (and continuing to
support multiple CD-ROMS).