On Fri, 15 Sep 2000, Eric G . Miller wrote:

> On Fri, Sep 15, 2000 at 01:34:00PM -0700, Peter Jay Salzman wrote:
> > there are 3 packages which work, but could be made **much** better,
> > considering the flack that debian gets as being the 'hard'
> > distribution.
> > 
> > for instance, it's absurd to install xfstt and not give the user a
> > heads up that they should:
> > 
> >     1. install fonts in /usr/share/fonts/truetop 
> >     2. add (or at least THE USER) a FontPath to XF86Config
> 
> /usr/share/doc/xfstt/README.Debian  First paragraph.
> 
> See also man xfstt and man xfs.
> 
> Most packages put a README in /usr/share/doc/<package>
 
right.  but unfortunately, that wasn't my point.  it would be _friendlier_ to
print 3 lines of text saying "hey, fonts go here and you'll want to place the
following line in your XF86Config".

> > and god forbid xfstt should come with a startup script placed in
> > init.d and symlinked to the relevant runlevels.
> 
> Funny, I got an init script.  Maybe it was missing in potato.  Doesn't
> seem likely though.

my bad.  i had to write one for suse, which is what i used to use.  sorry.

> > i'm only picking on xfstt because it was the first package i noticed
> > that really could be made MUCH better.  i would also like to say that
> > imwheel and netscape are also both deficient.   i mean, look at this:
> > 
> >    for d in \ /usr/lib/netscape/base-4/wrapper.d \
> >    /usr/lib/netscape/$VER/wrapper.d \
> >    /usr/lib/netscape/$VER/$BIN/wrapper.d ;do for f in $(ls -1 $d |
> >    sort); do . $d/$f done done
> > 
> > what's up with this?  why write a script that makes the user have to
> > see error messages every time they start up netscape?  shouldn't we
> > all KNOW where wrapper.d is?   it's not like this script run on a suse
> > system.
> 
> I don't KNOW what you mean... Variables allow programs/scripts to handle
> variable situations.  But yes, that script does kind of bug, since the
> errors are really just warnings that aren't important.
 
then to be more explicit: the maintainer of this package presumably is in
charge of where wrapper.d goes.  if someone wants to relocate it, the onus
is on that someone to modify this script.

knowing where wrapper.d goes, i don't see the need for variables/script to
handle the variable situations.  at least as far as the location of the
maintainer's own script directory goes.

i know the maintainers are competant people, but a 400 line wrapper script
for netscape?!?  puh-leez...

peter

Reply via email to