[Top][All Lists]
[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