Randolph Chung wrote:
>
> > Im getting bogged down with forks and IPC with the C based debconf stuff
> > i was attempting, i might have a quick look now.
>
> Glenn, is your code available some place?
>
> randolph
Hi, i was looking at purely the unpacking side of things, the idea was
to use pip
> Im getting bogged down with forks and IPC with the C based debconf stuff
> i was attempting, i might have a quick look now.
Glenn, is your code available some place?
randolph
--
Debian Developer <[EMAIL PROTECTED]>
http://www.TauSq.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
On Wed Aug 23, 2000 at 11:31:42PM -0700, Randolph Chung wrote:
>
> I just checked something into cvs. it's in tools/udpkg
>
This is so cool. You 'da man!
-Erik
--
Erik B. Andersen email: [EMAIL PROTECTED]
--This message was written using 73% post-consumer electrons--
--
To UNSUBSCRIBE
> This is probably more than sufficient as far as using it to install
> packages into the installer itself goes. I don't think we should ever
> need to install more than one package at a time, and if only one at a
> time is installed, your behavior is correct. I also don't anticipate
> this orderi
Randolph Chung wrote:
>
> > It looks like we should probably get further along on the redesign
> > so we can begin to get some better idea of what udpkg needs to be able
> > to do. Maybe we don't need dependencies. Maybe we do.
> >
> > (FWIW, Randolph is working on some 9 or 10k udpkg that does s
Randolph Chung wrote:
> It's really still very incomplete. It "supports deps" right now only in the
> sense that it will check dependencies against installed/to-be-installed-with-
> same-command packages. it doesn't do any of the ordering stuff yet,
> although the hooks are there. Dependency chec
> It looks like we should probably get further along on the redesign
> so we can begin to get some better idea of what udpkg needs to be able
> to do. Maybe we don't need dependencies. Maybe we do.
>
> (FWIW, Randolph is working on some 9 or 10k udpkg that does support
> deps.)
I just checked so
Anthony Towns wrote:
> 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.
udpkg is going to be used f
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
> > gu
> 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
>
On Mon Aug 21, 2000 at 11:25:55PM -0700, Joey Hess wrote:
>
> > unlike dpkg, dpkg-deb can quite easily be written as a shell script.
>
> I wrote most of it as a shell script, but I cannot find a way to parse
> control file entries w/o using external shell commands, which is
> something of a no-n
On Mon, Aug 21, 2000 at 09:10:57PM -0700, Joey Hess wrote:
> Erik Andersen wrote:
> > Doing depends will cetainly be too nasty for a shell scriot, so if we really
> > want to include depends, then I agree that doing udpkg in C is the way
> > to go.
> Yes, we really do need depends. As Randolph say
Randolph Chung wrote:
> not quite sure what you mean by "whole dependency tree checking" ...
More along the lines of what apt does, or what dpkg does; including
conflicts and so on.
> right now i am playing with this, and have it load the status file into
> memory, storing the package name and s
> Depends should be doable without doing a whole dependency tree checking
> thing. I'm thinking that when microdpkg is told to install a set of
> debs, it can simply update its in-core status data to reflect all of them
> being installed, and then iterate through each and make sure each would
> th
Erik Andersen wrote:
> Doing depends will cetainly be too nasty for a shell scriot, so if we really
> want to include depends, then I agree that doing udpkg in C is the way
> to go.
Yes, we really do need depends. As Randolph says, partly to make sure it
doesn't screw up a system too badly[1], an
On Mon Aug 21, 2000 at 06:32:09PM -0700, Randolph Chung wrote:
> > Maybe I'm missing something though (I almost certainly am), but do we really
> > need a 'microdpkg-deb'? Wouldn't just 'microdpkg' be enough? When we go to
> > install the base system, we really just want to unpack the .debs and
> Maybe I'm missing something though (I almost certainly am), but do we really
> need a 'microdpkg-deb'? Wouldn't just 'microdpkg' be enough? When we go to
> install the base system, we really just want to unpack the .debs and drop them
> into place. For this to take place we can do something l
On Sun Aug 20, 2000 at 09:25:14PM -0700, Joey Hess wrote:
>
> I think that just like dpkg, it should be split into two programs:
> microdpkg-deb to handles the low-level unpacking of packages, and
> microdpkg, to do dependency checking, and so on. Maybe this will turn
> out not to make sense; so
Joey Hess wrote:
>
>
> They will be written in C, or perhaps, in POSIX shell script (without
> any external commands except ar, tar, gunzip, though..).
>
If C, would it be ok if it was specific to busybox or would it have to
be independent?
If its writen specifically for busybox it could acce
The debian-installer is an effort to redesign and rewrite debian's
installer for woody. It's just getting started.
We've decided that the new installer will be modular, where modules are
maintained by separate people, and can be installed into the installer
itself while it is running, to give it
20 matches
Mail list logo
