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

Re: [debian-installer] microdpkg

On Tue, Aug 22, 2000 at 08:43:41PM -0700, Randolph Chung wrote:
> > How would you actually handle those dependencies though? Presumably you
> > don't have a udselect that'll automatically find any debs that anything
> > depends on, nor a uapt to do just automatically install them; you don't
> > guarantee any ordering so running udpkg -i foo.deb bar.deb won't bother
> > install bar before foo just because foo depends on bar...
> well, you *could* do ordering..... presumably if you have to handle
> depends, you need some sort of DAG to model the dependencies. it
> shouldn't be hard to do a topo-sort on the DAG to get what to install in
> what order.

Some of the ordering is pretty complicated, especially in the case of
circular dependencies. OTOH, you might not be able to get away without
some ordering. Dunno.

> if you do force-depends all the time there is no reason to write a
> program, you'd just use something like Erik's shell script that
> unpacks data.tar.gz to / and run things from control.tar.gz. if you
> force depends it almost doesn't make sense to update the status file...

Well, if you don't update the status file, dpkg can't later take over all
the management of your system. Ditto updating /var/lib/dpkg/info, and
whatever else dpkg needs to know about.

> > A uapt-get that lets you say "uapt-get install <foo>" and *does* cope
> > with resolving dependencies (but not conflicts, versions, or multiple
> > Packages files, perhaps) might be useful too, without being too difficult
> > or large. Hmmm. It really depends on what you want to use it for, though.
> are you volunteering to write this? ;-) in all seriousness, if someone
> wants to write a small but robust http/ftp fetch module for busybox
> that'd be awesome. perhaps all we need is snarf..... but in keeping with
> the modular approach this will let us integrate things in a more
> flexible manner.

Well, the "hmmm" was me thinking about it, but I'm really not sure what
it'd be for. If it doesn't support any of the `upgrade' variants, and
it doesn't care about ordering, *and* it doesn't care about conflicts,
*and* it doesn't care about versions, then you've just about done away
with all the hideously difficult parts of apt... But how it'd have to
work probably depends on how it fits in with the rest of debian-installer.

It also depends on what udpkg is going to be used for: there are probably
different design constraints if it has to work for populating a RAM disk
before doing anything compared to if you've already got some scratch
space on your hard disk.

Oh, I wonder if for busybox it might be reasonable to have it install its
binaries into /usr/lib/busybox/bin and just add that into the PATH rather
than conflicting with essential packages. No idea what implications that
might have, just wondering (or maybe /lib/busybox/bin, or even .../sbin
for a statically linked version for recovery purposes).

aj (who'd really like the boot-floppies debs to be actually useful on a
    fully installed system where possible)

Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

  ``We reject: kings, presidents, and voting.
                 We believe in: rough consensus and working code.''
                                      -- Dave Clark

Attachment: pgpFttYf9IEhJ.pgp
Description: PGP signature

Reply to: