[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Perl and other issues



Robert Sanders <gt8134b@acme.gatech.edu> 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.

Dan

--
Daniel Quinlan  <quinlan@spectrum.cs.bucknell.edu>


Reply to: