Re: Hurd sources distribution
On Tue, May 02, 2000 at 11:02:29PM +0200, Tomasz Wegrzanowski wrote:
> a)
> Are Hurd sources diffs available somewhere ?
Sorry, my omission. I always try to keep the debian directory uptodate in
CVS, and most of the time the rest is unchanged, so I don't package
upstream/diff, but only as a single tar file.
The very few cases I apply patches I will try to remember to put them
somewhere in debian/. Note that I always mention changes explicitly in the
debian changelog, so if it doesn't mention anything, nothing changed from
CVS.
> b) Why Hurd sources hasn't been splited ?
> b1)
> Linux compiles in half an hour on my machine (under Linux),
> and Hurd hasn't finished in 10 hours (under Hurd). I suppose Hurd
> is *much* more memory-consuming (it's 16MB RAM system), or
> I'm doing something very wrong (most of the time I wasn't looking, so
> I don't know what was happening), but it make playing with Hurd
> quite difficult.
Yes, the Hurd is somewhat bigger, and the fact that there are pic libraries
created as well doesn't make it better. Furthermore, native compilation is
always slower than cross compiling from linux (becuase of the general
slowiness of the hurd).
However, what would a split gain you, except that you have to compile
several packages? Maybe when all hurd libraries have versioned symbols a
split might become useful. This is something that will be decided by the
Hurd core when it becomes interesting.
> b2)
> Maximal machine power of Hurd machine is very limited.
> It supports 1 processor, 1GB partitions, probably not much
> of other resources (anyone has real numbers),
What "other resources" are there you care about?
(If someone has a SMP board, please work on SMP support in GNU Mach!
If you can't, send the board over to someone who can :)
> and
> compilation should be broken to parts that compiles on
> maximal supported machine in very reasonable time.
>
> It would be more clear which parts of Hurd changed recently,
> if only these ones changed their version.
I should include all changelogs in the package :)
> b4)
> dpkg was invented to support many little packages,
> huge, multi-functional packages aren't very compatible
Actually, huge packages which contain related stuff are much easier to
handle.
For now, please just accept that it is much more convenient for the
developers to keep the whole hurd source in single tree, although it might
this is not the Most Perfect Thing To Everyone.
There is a technical reason, too: The Hurd libraries don't carry versioned
symbols (actually, the latest libthreads does), and the soname is not kept
uptodate in CVS, so you might get obscure problems if you update only parts
of the Hurd and are not careful about it. With split packages, I would end
up to spent most of the packaging time in figuring out the correct
dependencies, and might still fail. This is not a workable solution.
Remember that we are working with development snapshots, as opposed to
released version.
A tip: Keep the build tree around. When updating the source code, the
Makefiles will only build the changed object files, resulting in a much
shorter build time.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server
Marcus Brinkmann GNU http://www.gnu.org for public PGP Key
Marcus.Brinkmann@ruhr-uni-bochum.de, marcus@gnu.org PGP Key ID 36E7CD09
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ brinkmd@debian.org
Reply to: