Re: tape deity

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

On Fri, 20 Mar 1998, Raul Miller wrote:

> I've been thinking about the issue of installing debian from tape
> vs. the powerful properties of installing packages in an appropriate
> order.
> 
> The obvious first issue to address is: what are the pros/cons of
> writing packages to tape in some specific order?

I'm going to make a statement here, it may not be true but I think with
some deeper considering it will lead to an answer to your problem.

Any given set of packages can be installed so long as they are ordered in
predepends order if the installer removes and deconfigures other
packages at will.

And a related statement, you may -NEVER- have predepends looping or
predepends+depends looping which means it is always possible to create an
order where all dependandants (and their dependants) of all predepends
come before the predepend.

It is not possible to install packages ordered in a random arbitary order
so long as predepends are involved.

The code in deity is designed to advoid explicit removes and deconfigures
as much as possible (but will use them if necessary). It does this by
re-ordering on a larger scope of conditions. [ie unpacking A before B
advoids the deconfigure of A if B were unpacked first]

I think it will work out that when installing from a media that has all
packages avail you will get minimal explicit removes+deconfigures but when
using something like a pair of CD's then you will get more
removes+deconfigures.

Actually, now that I think about it the above statements deserve more
consideration. Consider, that if the above is true it would be possible to
place all dependants of a pre-depends on the same CD, and thus they would
be available. It would then be possible to install in exactly -two-
stages.

That does leave the possibility of having packages seriously broken for a
large time due to conflicts removal. But - if all conflicts targets and
pre-depends targets were on the same CD then things would work out nicely,
only long-term explicit deconfigures would occur [which isn't so bad!]

Perhaps we need to say that things may not conflict or predepend on things
in a lower priority class?

Jason


--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org