Re: Debootstrap on GNU/Hurd Status
On Fri, Apr 11, 2003 at 02:42:45PM +0200, Michael Banck wrote:
> Here's the first difference already. Because quite some important
> packages are only available as experimental packages on alpha.gnu.org, I
> just made a list with the urls and fed it to wget.
Most of the packages on alpha have bug reports with patches open against
them. You will have to work through each of these and work with the
maintainer on getting a fixed and proper package into the archive.
> For the final log I've redirect MAKEDEV's output to /dev/null. Anyway,
> debootstrap normally just extracts devices.tar.gz, it would be nice if
> there was something like this for us, too. But what about the
tar doesn't support translator settings, but it should. When tar does, we
can have a tar file as well. Until then, it must be done with MAKEDEV.
> + for i in S 0 1 2 3 4 5 6; do mkdir -p $TARGET/etc/rc$i.d; done
> because glibc sets up update-rc-like stuff in /etc/rc?.d. The hurd
> package provides update-rc, but apparently not these directories. Either
> the hurd package should ship these directories, or some other package.
I ported sysvinit a couple of years ago, and the old and out of date patch
is in the Debian BTS. It never got any official acknowledgement of any
type. Privately, I got a reply that the package should be split into an
(source-wise) architecture independent base package with the programs, and
an architecture dependent package for the init scripts. That never happened.
For the Hurd, we want a better init system than sysvinit (Wolfgang seems to
work on one), but that doesn't exist yet.
> I'll file a bug against hurd for this issue soon if nobody objects.
The Hurd package just has a filthy kludge that makes it start the daemons at
boot time, and allows to use Debian without an init system. The only bug
report I want to see there is one that says that these kludges can be
removed (when they can).
> Everything else seems to work fine
> +# base="$(without_package "console-data" "$base")"
> + base="$(without_package "console-common" "$base")"
We don't use those.
> the commented out entries are packages which are present on alpha.gnu.org,
> except console-data, which James had exluded but is needed as a dependency for
The dependency should be fixed if it is architecture depending.
> Could somebody with more in-depth knowledge than me go through the above
> list and find out which packages we do not need and which package still
> need porting?
There is no in-depth knowledge needed. Patches need to be submitted, kept
up to date and revised until they are accepted upstream. For the console,
it's clear that we have a different console system and don't need (nor can
use) any of the Linux stuff.
> Other points about the above list:
> - The adduser package had to be put explicitely into $required, because
> hurd's postinst would fail otherwise:
> /var/lib/dpkg/info/hurd.postinst: line 29: adduser: command not found
> dpkg: error processing hurd (--configure):
> subprocess post-installation script returned error exit status 127
> I'll file a bug about this, too.
I think at that time base-passwd was arch all, and I didn't want to put the
special Hurd login user into that. Now this could possibly go into the base
> - Could we include dialog instead of whiptail as a debconf-frontend?
Not sure this has something to do with the Hurd, both should work (and if
they don't, they should be fixed).
> Well, this is the TODO-list I guess:
> - fix the hurd packege WRT adduser and /etc/rc?.d
Instead: Port or write an init system, then remove these kludges.
> - get those packages from alpha.gnu.org in the main archive
> - port/build missing packages
> - dpkg needs to be fixed (#187509)
> - devices/translators have to be setup in a nice way
Precondition: tar needs to be able to support translator settings. Don't
count on that happen any time soon.
`Rhubarb is no Egyptian god.' GNU http://www.gnu.org firstname.lastname@example.org
Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/