Quiet mode for pkg_install (was: Re: cvs commit: src/usr.sbin/pkg_install/info info.h main.c src/usr.sbin/pkg_install/lib global.c lib.h src/usr.sbin/pkg_install/version main.c perform.c pkg_version.1)

From: Alexander Leidinger (Alexander_at_Leidinger.net)
Date: 10/19/04

  • Next message: Maxim Sobolev: "[Fwd: What do people think about not installing a stripped /kernel ?]"
    Date: Tue, 19 Oct 2004 12:26:55 +0200
    To: obrien@freebsd.org
    
    

    Zitat von David O'Brien <obrien@freebsd.org>:

    [Moved to arch@]

    > One might want a list of packages for other things. I can't believe a
    > simple -q[uiet] switch is being bike shed. No, wait, this is FreeBSD I
    > *can* believe it.

    It's a nice feature, no objections, sorry if I sounded as if I object to it. But
    I think the implementation can be improved (from an usability point of view).
    When you use "-l", you already know if it is "<", "=" or ">", since you
    explicitely asked for it. So you don't need to have a "-q" switch here, it's
    enough to just omit the status indicator for "-l" by default.

    If you omit "-l" you don't need -q either, you can use ls to get a list of
    installed ports/packages when you don't want to see the status indicator.

    This covers all cases you seem to care about (judging from the commit log and
    your reply). For other cases (e.g. "-L") I don't see a need for a -q option.
    This doesn't mean much, I can't predict every use of pkg_version, but so far
    I'm not aware of someone who asked for such a feature. If you know someone who
    needs -q together with -L please tell me about it, I'm curious where it's
    needed.

    So it's not about bikesheding about "yes or no". It's about good usability. If
    you don't care about it, it's fine for me. I don't need this feature, so I spend
    my time on other (more important) things.

    Bye,
    Alexander.

    -- 
    http://www.Leidinger.net/     Alexander @ Leidinger.net: PGP ID = B0063FE7
    http://www.FreeBSD.org/        netchild @ FreeBSD.org  : PGP ID = 72077137
    Reisner's Rule of Conceptual Inertia:
    	If you think big enough, you'll never have to do it.
    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
    

  • Next message: Maxim Sobolev: "[Fwd: What do people think about not installing a stripped /kernel ?]"

    Relevant Pages

    • Re: No wonder Borland Technical Documentation stinks
      ... feature that would have been dropped/modified if the associated costs ... A therein lies what is probably the most common point of failure in software ... within their wished for budget and time constraints despite your objections, ...
      (borland.public.delphi.non-technical)
    • Re: Questions re: DAWs and MIDI sequencing
      ... Well, I explained what might be happening, by design. ... objections to this feature? ...
      (rec.audio.pro)
    • [patch 33/37] libata: clear TF before IDENTIFYing
      ... If anyone has any objections, ... libata: clear TF before IDENTIFYing ... Some devices chock if Feature is not clear when IDENTIFY is issued. ...
      (Linux-Kernel)
    • Re: A little bit else I would like to discuss
      ... I'd be fine with a fusion reactor, my objections would be if skynet ... at least 3 years to remove or change a feature. ...
      (comp.lang.python)
    • Re: How does this make you feel?
      ... the end user doesn't care in the least about computer architecture aesthetics. ... The only ways to completely work around it would have been super-ugly, like dynamically translating FP code to insert checks/fixups around FDIVs, or disabling the FPU and interpreting each FP opcode in a trap handler. ... Features that make life easier for apps programmers: ... This new feature might be appreciated by system programmers writing a new OS, because their fault handling code gets simpler, but will be pretty much invisible to the end user. ...
      (comp.arch)