Re: Simplifying bootstrap on circular-dependent packages
I would like to hear about the question, if you will.
"bootstrapping a partial system -- no kernel and no libc"
How does your local project indicate change wished or needed in debian's package build system? Or
in what way is it a request for special exception in build scripts?
I'm unsure why you [need to / did] edit libs. I've done so by hand down to the asm level and with
lib managers too - and with just shell scripts as libs runtime :)
But what are you doing? And what are you filing for?
* To: email@example.com
* Subject: Simplifying bootstrap on circular-dependent packages
* From: Daniel Ruoso <firstname.lastname@example.org>
* Date: Fri, 4 Nov 2011 17:30:23 -0400
* Message-id: <[🔎] CAA8KeO+SDJRcSGxgLTYDDcw+Gas+UXjH9HqV78tSA+k-V7806Q@mail.gmail.com>
I have been thinking about the bootstrapping of pakages lately. I am
involved in bootstrapping a partial system -- no kernel and no libc --
for some architectures for internal use. And I just thought that we
could use one trick to help in the bootstrap of packages that depend
on other shared libraries, this is something we use internally for
other reasons but I guess it could fit here as well.
The basic idea is creating "dummy libraries" that would serve for the
linking but that had no code on it. This would allow the linking to
happen -- of course this only helps in the case where the build
process doesn't run anything from the build-dependency.
Later the other package in the cycle would be built, and the actual
library would be made available instead of the "dummy", and the linker
would find the actual library.
We already extract all that information for dpkg-shlibdeps to work, we
could just build a fake shared library automatically based on that.
What do you think?