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

[Claudio Fontana]

On Wed, Jun 25, 2008 at 5:37 PM, Nicola Fontana <address@hidden> wrote:
> 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?

No, just saying. You will not find a similar behaviour in the
command line front-end, for example.

>> 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.

I think this change with gtk_entry_set_text, giving priority to
old_configure and autocheck can be merged.
I can do it myself if you don't mind, then I can commit the
whole thing.

>> > 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.

I think you are right, although I do not remember anymore
what I thought when I wrote that code, as a lot of time has
passed. Can you reproduce such a bug?

Thanks,

Claudio