bug-sourceinstall
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-sourceinstall] --prefix option not retained


From: Nicola Fontana
Subject: Re: [bug-sourceinstall] --prefix option not retained
Date: Wed, 25 Jun 2008 17:37:12 +0200

On Wed, 25 Jun 2008 16:07:36 +0200
Claudio Fontana <address@hidden> wrote:

> Nicola Fontana wrote:
> > Hi,
> > 
> > while upgrading packages I found another usability issue.
> > Following the golden rule of the less-surprise, I expect to do
> > the following:
> > 
> > 1. Choose the package
> > 2. Click upgrade
> > 3. Select the tarball or source directory
> > 4. Confirm the operation
> > 5. Leave the old configuration options and start the build
> > 
> > The problem is in 5.: all the configuration options are properly
> > retained, all but the --prefix one, overwrote by its global
> > value.
> > 
> > Having global option values is a great feature but while
> > upgrading I think the old options must have a higher precedence,
> > so once every package is properly installed, upgrading the whole
> > system will be a piece of cake.
> > 
> > I attached a patch (not deeply tested) that does the job.
> 
> Premise: the auto-check feature is not a libsrcinst feature,
> but a (relatively young) GTK front-end feature.

Do you mean I must build the patch local to the sourceinstall-gtk
CVS head?

> My opinion is that it is better to prioritize the old configured
> values, so I agree with the change.
> The only thing we need to remember is to deactivate the --prefix
> when it is not set in the old_configure string, like I wrote
> in the parallel thread about autochecking the checkbox.

Yes, as you stated I think it's enough to reset the checkbox
state after gtk_entry_set_text(). Tell me what do you need:
include this in the autocheck patch, merge these two patches or
whatever.

> > While writing it I noticed something weird on the parser that
> > gets the old values.  There is a single strstr() that searches
> > for the option name: what about if I have two arguments such as
> > --with-x-include and --with-x? Will be the --with-x old value
> > ignored in this case?
> 
> It should work correctly, see the code that follows the strstr.

I'm referring also to the following condition:

start[len] == ' ' || start[len] == '='

If looking for the "--with-x" key while old_configured contains
"--with-x-include=... --with-x=..." (just an example), strstr()
returns the first match and the condition fails: --with-x=...
will be not checked at all.

But maybe I'm missing something or this case is yet managed
while building the configure string.

Ciao
-- 
Nicola




reply via email to

[Prev in Thread] Current Thread [Next in Thread]