Re: util-linux [was Re: remote X applications]
[About porting util-linux]
On Sat, Jun 30, 2001 at 11:24:20AM +0800, Glenn Alexander wrote:
> Three possible results:
>
> 1) Programmer says: Nup (and we continue to port it ourselves).
>
> 2) Programmer says: Cool (I like to think this is probable)
>
> 3) Programmer says: Those HURD people are reaally nice. I might join the
> project. (Obviously the best response)
You see, we can include components of util-linux in GNU packages without
their consent even, and make Debian to use that (for the Hurd at least).
Obviously, we want consent. But the worst that can happen is that they
decline and we do it anyway.
This is a list that Roland sent me some time ago. If anybody wants to have
a go at negotiating between the GNU maintainers and the util-linux
maintainer (and probably help out moving the sources), please do.
Some tools could probably use a clean up so they match the GNU coding
standards etc. All these tools are very small, and I'd be glad to help out
with that.
On Sun, Jan 23, 2000 at 04:30:31PM -0500, Roland McGrath wrote:
Here is what I think ought to be done with util-linux. Many of its
programs should be in other GNU *utils packages (or reimplemented for
them). We can work with Jim Meyering and/or volunteers he knows to
get things into the *utils
These divisions are mostly already made in the util-linux sources, in fact.
Pretty generic, could go in sh-utils:
/bin/arch
Pretty generic, could go in textutils:
/bin/more
/usr/bin/rev
Everything in bsdmainutils should ideally go into textutils or sh-utils.
Also pretty generic, but also fairly useless; could go in sh-utils:
/usr/bin/setsid
/usr/bin/setterm
/usr/bin/mcookie
/usr/bin/whereis
/usr/bin/ddate
/usr/bin/getopt
Also pretty generic, but also fairly useless; could go in fileutils:
/usr/bin/namei
/usr/bin/chkdupexe
These could be made quasiportable and put in their own package:
/sbin/cfdisk
/sbin/fdisk
/sbin/sfdisk
These are portable (or easily made so) to anywhere with the sysvipc APIs.
(The Hurd has the APIs but they're all stubs that return ENOSYS.)
These could maybe go in sh-utils?
/usr/bin/ipcs
/usr/bin/ipcrm
Pretty Linux-specific, so I don't care where they go:
/bin/dmesg
/sbin/hwclock
/sbin/kbdrate
/sbin/fsck.minix
/sbin/mkfs
/sbin/mkfs.minix
/sbin/getty
/usr/sbin/readprofile
/usr/sbin/tunelp
/usr/sbin/cytune
/usr/sbin/rdev
/usr/sbin/swapdev
/usr/sbin/ramsize
/usr/sbin/vidmode
/usr/sbin/rootflags
/usr/bin/fdformat
This is actually quite portable (aside from the "guess default version"
part),
and people may want to use it on the Hurd too. It's just only of use for
systems that grok Linux swap signature pages (which as far as I know is
just Linux and Hurd).
/sbin/mkswap
For all the things that I call "pretty generic", it will be trivial for
Meyering or someone like him to incorporate them into *utils. Most of them
are simple enough that if there are copyright problems, a volunteer could
easily rewrite them too. At any rate, I think consulting with Meyering
about these ones is the thing to do for the ultimately desireable solution
(if not the immediately useful one for debian-hurd).
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann GNU http://www.gnu.org marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de
Reply to: