[ic] Upgrade procedure
emailgrant at gmail.com
Mon Jun 15 22:00:52 UTC 2009
>>>>>> 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:
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?
>>> 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)?
More information about the interchange-users