On Mar 14, Wookey wrote:
> OK. Looks like I should join another list (help I'm sinking in
> email!)
Glad to have you on board Wookey. I've always hoped that Emdebian and
Familiar could collaborate on areas such as this.
> Debian is all built natively so 'gcc' is the answer. This makes sense because
...
> Are we sure we want to cross-build everything in the autobuild system? If not
> then we can probably use Debian's system approximately as-is (somehwat
> simplified). Phil understands it better than I, but I'm sure this is quite
> do-able.
I don't think we want to cross-build everything, at least not
initially. If we would like to augment some system at some point to
support cross-compilation then that might be interesting.
I think it makes sense to start with a straight Debian build system
and go from there. Doesn't CRL have a machine setup for this? I seem
to remember hearing something about that at some point.
> The main problem with it is that much of it isn't yet packaged or
> well-documented, so it requires some investment in time to work out
> how things fit together enough to be able to work out how to adjust
> things for this purpose.
Right. A lot of the difficulty with Familiar has been that most of the
first packages were not built from source at all but were cobbled
together from various binary pieces. And ever since, we've just been
living with the same packages. I've been wanting to change that for
quite some time. The good thing is that Debian source packages do have
the bits that we need where we have not been maintaining custom
source.
> Things like the simplified dependency system of familair wrt debian
My goal has always been that the "simplified dependency system of
familiar" should still be compatible with the Debian dependency
tree.
For example, I'm now considering breaking up shellutils and fileutils
into multiple packages, (eg. core vs. obscure). That way, new packages
will be able to depend on shellutils-core for example, and we can keep
Familiar small.
Then, to still provide Debian-compatibility, we need to still have a
shellutils package that provides no files, just dependencies on
shellutils-core and shellutils-obscure. That way, our slimmed down
packages won't break any Debian package, and we'll have the
possibility of contributing more fine-grained packages back to Debian.
So, the real work that needs to be done is to take all the existing
trimmed-down Familiar packages, realign them with Debian dependencies,
and also code the support for building those packages from straight
Debian source. This is all work that I plan to do.
But, really, that doesn't have any direct impact on the design or
implementation of the build-system, so no need to wait for me. ;-)
-Carl
-- Carl Worth USC Information Sciences Institute cworth@east.isi.edu 3811 N. Fairfax Dr. #200, Arlington VA 22203 703-812-3725Received on Thu Mar 14 15:16:25 2002
This archive was generated by hypermail 2.1.8 : Tue May 04 2004 - 08:45:19 EDT