Re: post-release package update policy
On Fri, 3 Nov 1995, Thomas Kocourek wrote:
> On Mon, 23 Oct 95 12:33 GMT, debian-user@Pixar.com wrote:
>
> [...]
> I agree about the second item (bugs). How about a list of "version numbers"
> per each official release? Given such a list (which would state the minimum
> version numbers for a "stable" release), I could compare those numbers when
> I have trouble and know if it is just an old package. I'm sure that
> sites which are short on storage space would much rather have a highly
> compressable text file than another "tree" of packages. The "PACKAGES" list
> could be used for this purpose.
> A second list would have the most current version number of all packages
> (including the kernel version). This second list would be constantly updated
> as packages are updated. The second list would make known which packages
> are the "bleeding edge" packages as well as which are "bug fix" packages.
> Again, this list would be a highly compressable text file.
> Any comments?
>
[This message is a bit long.. but I think it would be interrestiwant to
expain some essential features of the system first, so bear with me]
I'd like to inform you about a system that we use at our university and
several other Norwegian universities. It is called 'store' and is a bit
similar to the debian system. An important difference is however that this
system is supposed to support several different operating systems and it
does not contain 'low-level' applications that are os-specific. None of
the applications currently supported (about 450 applications) would be
installed on the root system of the os (at least none that I know of).
The store system is also a bit NFS centric because the universities are
its main users but the design decisions could equally apply to package
systems like debian.
Each machine has one or more 'stores'. A store is a collection of
applications (or packets as debian calls it). We typically have two stores
on each server on our university. One for 'free' software and one for
commercial application (typically site-licenced applications etc.). Each
of the stores consists of application. Each application has _several_
versions, each accompanied with a 'grade' which is one of
prealpha/alpha/beta/gamma/release/stable/dated/old/obsolete. The grades
are set by the person responsible for the application. In addition to
this, each application has support for a set of architectures which are
organized as a tree. We currently only have i386-based linux boxes, but a
hierarchy for linux could be:
all
[...]
linux
linuxi386
linuxi386aout
linuxi386elf
linuxalpha
linuxalphaaout
linuxalphaelf
As an example, a application consisting of only scripts could support the
'linux' architecture while a binary application could support
'linuxi386aout' and 'linuxalphaaout'. Currently we have a tree consisting
of about 100 architectures.
[In certain contexts, having a tree like the one we're using have
drawbacks - other solutions include a DAG and using separate os/machine
trees]
[In addition to this, we also have a domain tree and 'domain'-specific
files, but that's not very interresting in this forum..]
Dependencies and such are also stored together with the application in
the store.
Ok.. so we have several stores with different kinds of applications. How
do we select which to use?
This is done by making a 'user-profile' which tells the system what kind
of user you are. Different 'profiles' will rank the 'grades' given to
applications differently. We have currently 5 defined 'profiles': newer,
gamma, normal, older and conserv. If we use the 'newer' profile, we want
to run the latest software (i.e. versions graded 'alpha' would be used
before 'release') etc.
Based on a 'user-profile' we make a _link tree_ which points into the
'best-fitted' version and store based on our preferences.
There are lots of other considerations in such a system, but the thing
I'd like to say is that this can be done! (..it has been done and it works
great!)
astor
PS: I'm just a user of this system, not an implementer. The
implementation consists of about 12000 lines of perl code and is
available at ftp.unit.no:/local/store
Reply to: