This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

--__==========00000000030451==pmi-kc.com==__
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.NEB.4.21.0001142123402.12327@oblivion.mono.org>

> On Fri, 14 Jan 2000, gkrall wrote:
> 
> How about loading the dependent packages from the bottom of the
> dependancy tree first?  That way if the pkg_add command fails in the
> middle (from modem droppage) you would only loose on the dependent pkg
> currently being installed and not any dependent pkg further upstream
> from the final (initial) package request.
> 
> In other words I want to load pkg A.  A depends on B&X, B depends on
> C&D.  So install/Register C&D first; Then B&X; then finally A.  And if
> it fails on B I don't have to waste bandwidth on C&D again.....unless of
> course that would introduce an Nth-order Fibernacci level of complexity.
> 
> 
> A+---B+---C
>  |    |
>  |    +---D
>  +---X
> 
> Then of course I s'pose i could just get a cable modem, stop whining and
> I wouldn't run into droppage any more.
> 
	The problem is you do not know the depends for a package until
	you have downloaded and extracted it.
	
	The generic 'fetch binary packages to local PACKAGES directory'
	option probably makes the most sense.

> PS. I think(hope) I fixed my mime problem. sorry if I didn't.

	I'm afraid not :)

--__==========00000000030451==pmi-kc.com==__
Content-Type: TEXT/PLAIN; CHARSET=us-ascii
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID: <Pine.NEB.4.21.0001142123403.12327@oblivion.mono.org>
Content-Description: 

*This message was received using a trial version of CommuniGate(tm) SMTP*
--__==========00000000030451==pmi-kc.com==__
Content-Type: TEXT/PLAIN; CHARSET=us-ascii
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID: <Pine.NEB.4.21.0001142123404.12327@oblivion.mono.org>
Content-Description: 

=0D
How about loading the dependent packages from the bottom of the=0D
dependancy tree first?  That way if the pkg_add command fails in the=0D
middle (from modem droppage) you would only loose on the dependent pkg=0D
currently being installed and not any dependent pkg further upstream=0D
from the final (initial) package request.=0D
=0D
In other words I want to load pkg A.  A depends on B&X, B depends on=0D
C&D.  So install/Register C&D first; Then B&X; then finally A.  And if=0D
it fails on B I don't have to waste bandwidth on C&D again.....unless of=0D
course that would introduce an Nth-order Fibernacci level of complexity.=0D
=0D
=0D
A+---B+---C=0D
 |    |=0D
 |    +---D=0D
 +---X=0D
=0D
Then of course I s'pose i could just get a cable modem, stop whining and=0D
I wouldn't run into droppage any more.=0D
=0D
Gerald=0D
=0D
PS. I think(hope) I fixed my mime problem. sorry if I didn't.=0D
=0D
=0D
=0D
Hubert Feyrer wrote:=0D
=0D
> On Thu, 13 Jan 2000, gkrall wrote:=0D
> > I've noticed that if I start a pkg_add command and that pkg depends on=
=0D
> > other pkgs, and if the modem drops line some where on the 2nd or 3rd=0D
> > dependent 5meg pkg I loose & have to start over.  Is there a way to=0D
> > resume a stalled pkg_add command so that time/bandwidth isn't wasted?=
=0D
>=20=0D
> Nope, sorry.=0D
>=20=0D
> > I've successfully reget an ftp item before and wondered if there was an=
=0D
> > analog in the package system?  Since pkg_add uses anon ftp could this=
=0D
> > functionallity be added by tracking whats been DL'ed (and what the temp=
=0D
> > file name is) and issuing a reget type command in the pkg that didn't=
=0D
> > complete?=0D
>=20=0D
> No, because we pipe the downloaded package immediately into a "tar vxf -"=
=0D
> to not waste the diskspace for holding the pkg twice.=0D
>=20=0D
>  - Hubert=0D
>=20=0D
> --=0D
> NetBSD - Better for your uptime than Viagra
--__==========00000000030451==pmi-kc.com==__--