[Top][All Lists]

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

Re: libdiskfs: build system inconsistencies; the Hurd `collecting box'

From: Thomas Schwinge
Subject: Re: libdiskfs: build system inconsistencies; the Hurd `collecting box'
Date: Wed, 8 Feb 2006 06:13:28 -0500
User-agent: Mutt/1.5.6+20040907i

On Tue, Feb 07, 2006 at 06:36:36PM +0100, Alfred M. Szmidt wrote:
> Could you elaborate on the two solutions and how the differ (are
> better) than just adding the proper libraries to HURDLIBS?

``Adding the proper libraries to HURDLIBS'' is basically the first
sugestion, combined with a reliable mechanism to make sure that
discrepancies will always be noticed (and do not lead to at first
incomprehensible--like in the example I gave--or--maybe even more
dangerous--silent breakage).  This could be implemented by checking each
generated dependency file about not including any files from

Solution two is splitting the Hurd `collecting box' into a lot of
smaller, independent packages.  There would be a package `libihash',
which is configured, built and installed into /lib/ and /include/ and
then the packages that depend on libihash's functionality can be
configured and built, using the libihash that was previously installed
into /lib/ and /include/.  Etc.

Obviously this leads to a lot of packages, given the number of
`functional units' that are contained in the current Hurd `collecting
box'.  The question is, whether parts of them can be combined reasonably,
reducing the number of packages the Hurd would be split into.

This second suggestion is relevant, because we have to decide which
libraries and translators should be part of the main Hurd package and
which shouldn't.  Why is `ftpfs' part of it, but not `httpfs', `smbfs' or
`gopherfs'.  And now, don't say ``because those three are not mature
enough'' (which `ftpfs' also isn't: there is e.g. no write support iIrc);
there will be the day they are mature enough and will they be included
then?  Will `reiserfs', `romfs', `ext3fs', `xfs', `zfs', `lvm',
`pfinet_ipv6', `ethernet_bridge', `cvsfs', `gnu_arch_fs', `tarfs',
`xmlfs', `rollover', `contabfs', etc. also be included?  Likewise for the
libraries.  Or the other way round: why are `fatfs' and `ufs' part of the
main Hurd package, apart from historical reasons, under the assumtion
that they are not widely used.  Where will be the boundary for inclusion
vs. refusal of inclusion?  I think we agree that the core Hurd package
can not contain each and every translator people come up with.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]