All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jaromir Capik <jcapik@redhat.com>
To: lm-sensors@vger.kernel.org
Subject: Re: [lm-sensors] [PATCH] man pages for eepro* tools & fixing missing i2cset switch
Date: Mon, 07 Oct 2013 14:49:40 +0000	[thread overview]
Message-ID: <1450579748.2250803.1381157380670.JavaMail.root@redhat.com> (raw)
In-Reply-To: <2130321044.1321494.1380882265184.JavaMail.root@redhat.com>

> Hi Jaromir,

Hi Jean.


> > Please, check/modify/merge.
> 
> This should really have been two patches. Besides, I'm not too happy
> with the i2cset man page fix. It's not bad per se but I would prefer to
> keep the help text consistent amongst i2c tools. So I've only added the
> missing flag for now [1]. If you want to make the help text more
> verbose then please send a separate patch doing it for all i2c tools
> (i2cdump, i2cdetect, i2cget and i2cset.)

I didn't want to cause line wrappings on terminals with 80 characters
per line. But if you're ok with that, then I'm too.


> The man pages for eeprom, eepromer and eeprog look overall good, but I
> would like to mention two things.
> 
> Firstly, in the long run, I really would like to get rid of two of
> these tools and keep only one. They serve the same purpose, only the
> EEPROM chips supported and the way to access them is different.

I'm perfectly ok with that. I had to create the man pages to make
our products sane and even if the live expectations of the man pages
are short, I consider it a good idea to merge them upstream for someone
who decides to build the current version in the future (for whatever reason).


> Secondly, I am really not sure in which category the man pages belong.
> "System Administration" seems wrong to me, as the most common use case
> for these tools is to flash an EEPROM temporarily connected to the
> system (typically over the parallel bus or USB) for it to then be used
> on a different system. It's somewhat similar to a cross-compiler, so
> it's more about development than system administration. Sure, these
> tools can only be used by root, but it is really only because handling
> permissions on /dev/i2c* nodes is not so easy.
> 
> As a consequence, I don't know if these tools should go to /usr/sbin
> (because in practice only root can use them) or in /usr/bin (because
> they are not system administration tools proper.) Likewise, I don't
> know if they should go to man page section 1 (General commands), or 8
> (System administration commands.) Opinion anyone?

Life's difficult :]
I believe users do not care about this stuff as long as there's only
one manpage per tool. The same applies to the binary location.
As long as it is reachable via the PATH variable, there's no need for
worries about the location.


> --
> Jean Delvare
 
Regards,
Jaromir.

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

  parent reply	other threads:[~2013-10-07 14:49 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-04 10:24 [lm-sensors] [PATCH] man pages for eepro* tools & fixing missing i2cset switch Jaromir Capik
2013-10-06 19:47 ` Jean Delvare
2013-10-07 14:49 ` Jaromir Capik [this message]
2013-10-16 15:05 ` Jean Delvare

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1450579748.2250803.1381157380670.JavaMail.root@redhat.com \
    --to=jcapik@redhat.com \
    --cc=lm-sensors@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.