Re: Perl and other issues
Robert Sanders <firstname.lastname@example.org> writes:
> 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:
> # Set hostname and domainname
> /bin/hostname `cat /etc/HOSTNAME`
> /bin/domainname `cat /etc/DOMAINNAME`
Eeeck. How about:
/bin/hostname < /etc/HOSTNAME
> is one possible solution.
> 3) If you don't install the xtralib package (or whatever it's
> called) to get libg, compiling with -g won't work. If xtralib
> isn't installed, /usr/lib/libg.a should be a symlink to
> /usr/lib/libc.a (or similarly with lib[cg].sa). I'm not sure of
> the utility of a real libg.a without libc source online anyway.
Double-ly good point. I just discovered a few days ago that I can't
debug for sh** since I didn't have the libc source online. Sorry for
not bringing this up the moment I noticed it, but I've been busy.
Oddly enough, I was trying to debug a program for Debian.
> 4) selection is resident in /usr/bin but is invoked (in rc.M) from
> /usr/sbin. One of these should be altered.
Sounds like a /usr/sbin binary, but I could be wrong. Users can use
it... sure, but it should only be started once. From a /etc file.
> 5) If the idea of rewriting dpkg in perl is still alive, I may be able to
> help: I have a working curseperl using native Linux (BSD) curses. I also
> have a much more featureful ncurseperl using ncurses and the panel(3)
> library for overlapping windows and menus. I'm using this for my
> (temporarily on-hold) ext2fsperl dfs debugger/undelete/etc project.
C is much better for this specific task, I think.
> 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 agreed 100% with your two postings on the subject.
Daniel Quinlan <email@example.com>