All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lubomir Kundrak <lkundrak@redhat.com>
To: Hollis Blanchard <hollis@penguinppc.org>
Cc: The development of GRUB 2 <grub-devel@gnu.org>, okuji@enbug.org
Subject: Re: [PATCH] [UPDATE 2] More enhanced GNU GRUB program name transformations
Date: Wed, 14 Feb 2007 11:38:48 +0100	[thread overview]
Message-ID: <1171449528.17109.42.camel@pluto.brq.redhat.com> (raw)
In-Reply-To: <1171394175.23399.41.camel@basalt>

Hi,

On Tue, 2007-02-13 at 13:16 -0600, Hollis Blanchard wrote:
> On Tue, 2007-02-13 at 17:30 +0100, Lubomir Kundrak wrote:
> > Hi Hollis,
> > 
> > On Mon, 2007-02-12 at 19:01 -0600, Hollis Blanchard wrote:
> > > On Mon, 2007-02-12 at 00:20 -0600, Jerone Young wrote:
> > > > 
> > > > This patch is derived from the patch sent earlier by Lubomir Kundrak.
> > > > What this patch adds is for library directories and directories in
> > > > /boot to be changed as well. So the user can easily launch
> > > > 
> > > > ./configure --program-transform-name="s/grub/grub2/" 
> > > 
> > > This seems a little over-engineered to me. Why not just rename all the
> > > grub2 stuff to be "grub2-*" to begin with?
> > 
> > Do you think it is a good practice to rename the program names by
> > default? In my opinion is not the good place to tell what version of the
> > program the binary belongs to. This technique is commonly used to
> > separate versions of software when more than one version it is in use --
> > temporarily, till it gets wider acceptance.
> 
> So users will have both grub-* and grub2-* installed? When grub2 is the
> default, they and all their scripts will need to learn to run grub2-*
> instead of grub-*. Then one day grub1 will be removed, grub2 will be
> renamed to grub-*, and the user must learn this and all those tools will
> need to be reverted to call grub-* again?

I don't think that GRUB is a think that users tend to use in scripts.

This practice (name transformation) is currently used happily by Debian
to make two versions of Apache HTTPD coexist, by vendors who use
multiple versions of Berkeley DB, by UNIX and BSD systems who provide
GNU versions of their tools etc. In my opinion chance of causing
conflicts and confisuion is even considerably smaller for GNU GRUB.

> I don't think changing the name more than once is a good idea. And if
> we're only going to change it once, let's just do it and avoid this
> transform stuff.

Transformation means that it is not us who change the name. It is an
option for the end-users who wish to have both versions installed. At
least till it is in development, many users will want to avoid conflicts
between the two version, while from long-time perspective it makes
little sense to call everything grub2-*.

It might be argued that this will become of no use once GRUB 2 is
stable. In that case the benefits are ability to have even multiple
versions of GRUB 2 installed (might be useful for debugging) or when one
day GRUB 3 comes out, people could retain their GRUB 2s as grub2-*.

> > That's why I think it is
> > good that it is configurable. Additionally we merely use autoconf's
> > feature, not add or invent new stuff, so it hardly can be called
> > over-engineering.
> 
> All those | sed "$(transform)" additions don't look like an autoconf
> feature to me...

It is documented as example implementation of using AC_ARG_PROGRAM in
GNU Autoconf manual, chapter 12.5 "Transforming Program Names When
Installing".

> -Hollis

Regards,
-- 
Lubomir Kundrak (Red Hat Security Response Team)




  reply	other threads:[~2007-02-14 10:39 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-12  6:20 [PATCH] [UPDATE 2] More enhanced GNU GRUB program name transformations Jerone Young
2007-02-13  1:01 ` Hollis Blanchard
2007-02-13 16:30   ` Lubomir Kundrak
2007-02-13 19:16     ` Hollis Blanchard
2007-02-14 10:38       ` Lubomir Kundrak [this message]
2007-02-14 20:12 ` Yoshinori K. Okuji
2007-02-17 22:39   ` Jerone Young
2007-03-05  2:35     ` Jerone Young
2007-03-05 17:06       ` Yoshinori K. Okuji

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=1171449528.17109.42.camel@pluto.brq.redhat.com \
    --to=lkundrak@redhat.com \
    --cc=grub-devel@gnu.org \
    --cc=hollis@penguinppc.org \
    --cc=okuji@enbug.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.