All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans Reiser <reiser@namesys.com>
To: "Philippe Gramoullé" <philippe@gramoulle.com>
Cc: reiserfs-list@namesys.com, vitaly@thebsh.namesys.com
Subject: Re: need opinions from sysadmins on where reiser4progs should install
Date: Sun, 20 Nov 2005 23:09:01 -0800	[thread overview]
Message-ID: <4381728D.7030300@namesys.com> (raw)
In-Reply-To: <20051120115529.633B1177A@philou.gramoulle.local>

Philippe Gramoullé wrote:

>Hello,
>
>On Sun, 20 Nov 2005 05:07:23 +0100
>rvalles <rvalles@es.gnu.org> wrote:
>
>  | When I run make install on something and haven't specified a prefix on
>  | configure, I expect /usr/local to be used. If I wanted /, I'd have
>  | specified that on configure time. If it installed in / by default, it
>  | would, often, hit the "sacred package-system managed area" of the VFS
>  | tree annoying people like me to a very great extend, so please don't.
>
>While i totally agree with you for standard packages, well i based my choice
>on actual experience of the last past six years of use with reiserfs V3.
>
>I can't remember how many times i heard Namesys team say " Install the latest
>& greatest reiserfsck", how many times distro thought they knew reiserfsprogs
>internals better than Namesys and customized it to the point where it would
>eventually break.
>
>Of course, i can live with a manual install of reiser(fs|4)progs, so i don't
>really mind, but talking of support, it can make quite a difference to Namesys
>in terms of support, and annoyance with bug reports that could have been easily
>avoided.
>  
>
Ok, I propose the following: search the standard locations for where it
is currently, tell the user, ask the user if they want to rename those
versions to *.old if the install of the new one succeeds, and then
prompt for the install location with /sbin as the suggested default.  I
think that unlike other user installed programs, fsck does not belong in
/usr/local.  I think Philippe's point that old versions are dangerous is
quite valid.

>Final decision will still be Namesys call, but hopefully this whole thread gave
>them some valuable input to make the best decision.
>
>Thanks,
>
>Philippe
>
>
>  
>


  reply	other threads:[~2005-11-21  7:09 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20051120040723.GA1392@148.Red-217-126-33.pooles.rima-tde.net.>
2005-11-20 11:55 ` need opinions from sysadmins on where reiser4progs should install Philippe Gramoullé
2005-11-21  7:09   ` Hans Reiser [this message]
2005-11-21  7:33     ` Hubert Chan
2005-11-21 13:32     ` Vitaly Fertman
2005-11-21 18:07       ` Hans Reiser
2005-11-22  0:04         ` michael chang
2005-11-22 19:33           ` David Masover
2005-11-22 20:14             ` Hubert Chan
2005-11-25 16:54             ` Chester R. Hosey
2005-11-13  7:17 Hans Reiser
2005-11-13 11:08 ` Petteri Räty
2005-11-13 15:37 ` Gorazd Golob
2005-11-13 17:42 ` Clifford Beshers
2005-11-17  4:56   ` Hans Reiser
2005-11-17  6:01     ` Paul Jarc
2005-11-14 20:50 ` Tom Vier
2005-11-14 22:26 ` Hubert Chan
2005-11-17 16:06 ` Philippe Gramoullé
2005-11-20  4:07   ` rvalles

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=4381728D.7030300@namesys.com \
    --to=reiser@namesys.com \
    --cc=philippe@gramoulle.com \
    --cc=reiserfs-list@namesys.com \
    --cc=vitaly@thebsh.namesys.com \
    /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.