[ic] Upgrade procedure

[Grant]

>>>>>> Database variable scalar parameter VARIABLE.TXT redefined to "TAB", was "TAB".
>>>>> You have a duplicate Database line for your variable database.  check
>>>>> your catalog.cfg and included files (including files in the dbconf
>>>>> directory and subdirectories).
>>>> You're right, I had variable.dbm in both dbconf/default_db and
>>>> dbconf/mysql.  I noticed I also have identical access.dbm and
>>>> mv_metadata.dbm files in those locations.  Does variable have special
>>>> handling in this case?
>>> Only the ones in the mysql directory should get pulled in.  Check your
>>> catalog.cfg for an extra Database line for the variable file.

I do have in catalog.cfg:

VariableDatabase variable

Does that refer specifically to dbconf/default_db/variable.dbm?  I'm
afraid to remove the line to find out.

>> The message actually disappeared after I removed the line from
>> dbconf/default_db/variable.dbm.  A bug maybe?
>
> Only one of the two directories should get pulled in from your
> catalog.cfg, so check that and any files included from that.  Certain
> variables set in the variables.txt file itself can control the flow of
> things in catalog.cfg, explicitly where control of which db is pulled in
> is concerned.
>
>>>>>> Warning while compiling UserTag 'ups_query':
>>>>>> "my" variable $result masks earlier declaration in same scope at
>>>>>> /usr/lib/perl5/vendor_perl/5.8.8/Business/UPS.pm line 97, <SYSTAG>
>>>>>> line 154.
>>>>> This is an issue with Business::UPS and needs to be taken up with the
>>>>> author of that module.  It is porobably safe to ignore the warning, though.
>>>> OK but should that usertag be disincluded from IC since it has a problem?
>>>>
>>>> code/UserTag/ups_query.tag
>>> If you're not using ups then you should be able to exclude the usertag
>>> without problems.  I would not consider the warning you mention to be
>>> enough of a "problem" to merit removing the usertag from IC.
>>
>> A fresh installation of IC throwing a warning upon start/restart seems
>> to me like it should be fixed, but it's not a big deal.  I renamed
>> ups_query.tag to ups_query.tag.conflict and the warning disappeared.
>
> Yes and no.  The warning is not coming from any Interchange code itself,
> but from the module.  It is even possible that you have a specific
> version of the module which throws the warning.  At any rate, given a
> choice between having functionality and a warning or having to implement
> such a broad range of functionality ourselves or removing the
> functionality generally having the functionality and the warning wins out.
>
> If it were an Interchange bug causing the warning then you would be correct.

I see what you're saying, so the conflict is due to a problem with
/usr/lib/perl5/vendor_perl/5.8.8/Business/UPS.pm, not a problem with
ups_query.tag.  Do you know which version would be pulled in by
Interchange::Bundle?  It looks like Business-UPS-2.0 is the latest.  I
can't find mention of the version in the installed module's source.
If Interchange::Bundle pulls in the latest Business::UPS, isn't it
fair to say there is a problem with ups_query.tag (which is
distributed with IC)?

- Grant