Perl and other issues
Date: Sun, 27 Feb 94 22:40 PST
From: gt8134b@acme.gatech.edu (Robert Sanders)
1) The Perl package includes an incorrect perl binary and does not
include two binaries that it should. The problem with
/usr/bin/perl can be demonstrated by running it through the perl
test suite; it will fail on the pipe test. This is caused by an
incorrect signal list, and affects much more than pipes.
Yes. Someone pointed this problem out last week. I tried recompiling
with -D__USE_BSD_SIGNAL and it still failed the pipe test. Any
suggestions?
Also, because the Linux kernel disallows setuid scripts because
of security problems, perl needs to be compiled for setuid
emulation.
Good point.
Lastly, for non-STDSTDIO systems, the -T and -B operators (test
for text or binary files) fail for non-lseekable files. I have
a patch to fix this.
I'd appreciate the patch.
2) The hostname and domainname are not set separately. Installing
the hostname from net-0.32, symlinking /bin/domainname to hostname,
splitting the host.domain name in /etc/HOSTNAME into host in
/etc/HOSTNAME and domain in /etc/DOMAINNAME, and changing the
hostname line in /etc/rc.d/rc.inet1 to:
Debian 0.92 is now using the hostname/domainname pair from util-linux
1.5, and /etc/rc.d/rc.inet1 now reads:
[...]
/bin/hostname debra
/bin/domainname debian.org
[...]
Acceptable?
4) selection is resident in /usr/bin but is invoked (in rc.M) from
/usr/sbin. One of these should be altered.
It should have been /usr/bin in the rc script. Simple oversight, and
fixed for 0.92.
Regarding dpkg -> perl, we're working on a C version. Not in 0.92,
but soon...
6) I have a slightly primitive perl script that will take a list of
files and generate a package from it. I hear that development on
packaging tools is already going on, so I will consider this a
stopgap measure. However, if there is enough interest, I could
clean this up and release it when I have some spare time to fill
the gap until the 'real thing' is released.
I'd be interested in taking a look at it, at the very least. If it
does the job, then I see no problem with releasing it until I get the
`real' one done.
7) I wasn't yet on the debian-devel list when I mailed my package
dependency letter (due to a listserv bug, I think). So, to recap,
I think that each package should include a list of packages upon
which it depends instead of the current scheme of knowing which
packages depend on it. Did this suggestion receive any comments?
If so, please restate them for me.
I agree. I'm doing quite a bit of reorganization in the dpkg system
for 0.92. You're quite right; packages should have more control over
their own destiny. Your comments on the subject have been most useful
in my re-evaluation of how the dpkg system works and how it could be
made better.
Upgrades I think would be helpful and why:
------------------------------------------
(ar, gas, gprof, ld, nm, objdump, ranlib, size, strip) from
binutils-1.9l.3-as-2.2l.tar.gz - support for QMAGIC binaries
In.
/sbin/arp /bin/hostname /bin/domainname /sbin/ifconfig /bin/netstat
/sbin/route /sbin/slattach from net-0.32 - greater functionality
and domainname
In (except for hostname... should I be using this one instead of the
util-linux hostname/domainname pair? At present 0.92 has done away
with /etc/HOSTNAME entirely.)
/usr/sbin/syslogd /usr/sbin/klogd from sysklogd-1.1 - fixes "loose
cannons" bug in syslogd
I've been working on this one, and I can't seem to get it to compile.
I'll mail more details tonight when I'm at home and can paste the
output into my message.
* LISP development (CLISP)
I'm very interested in getting this into the `devel' category.
* Communications (term, sz/rz/sb/rb/sx/rx, etc.)
term will be in 0.92, and sz/rz/... will be soon to follow.
As far as the math packages go, you should talk to... damn, what is
his name, Mike? (Sorry, I can't remember his name. Mike?) Anyway,
he, too, is interested in putting together math packages for Debian
similar to the ones that you mentioned. These types of packages would
probably best fit the definition of `contrib' packages, unless there
is widespread interest in their inclusion into the distribution
proper.
Regarding `contrib' submissions:
I'll put (almost) anything in `contrib', as long as it's not
commercial software, etc. I do want to keep the actual distribution
small; in fact, I hope that it doesn't grow much more than its current
size, though TeX will be in 0.92 and there are a few other packages
that I'd like to get into the actual distribution soon. But if you
want to put together a package for Debian, as long as it conforms to
the dpkg packaging guidelines (soon... :) and is packaged properly, it
will be made available in `contrib'. My hope is that soon, with
individuals contributing a wide variety of packages, Debian users have
their favorite software available in dpkg format without forcing the
distribution to suffer from the "Kitchen Sink Syndrome".
Thanks for the great comments, Robert. I'm very glad you decided
to become involved.
Ian
Reply to: