obsolete registered extensions

[Stephan Bergmann]

On 11/06/2017 10:16 AM, Michael Meeks wrote:
> On 06/11/17 07:42, Noel Grandin wrote:
>> I just saw a comment
>>
>>      // Class to read obsolete registered extensions
>>      // should be removed for LibreOffice 4.0
>>
>> which appears to have been introduced in
>>
>>     commit 042247b3e428cb7352c06a670576819c67378090
>>     Author: Michael Meeks <michael.meeks at suse.com>
>>      Date:   Wed Nov 16 16:59:39 2011 +0000
>>
>>      Fixup legacy sleepycat db database usage for packages
>>
>>      Previously empty legacy registered_packages.db databases were created
>>      unconditionally, at some efficiency and startup cost, despite these
>>      being deprectated since before version 3.2.
>>      We now handle version mismatches by warning on the console and ignoring
>>      these files.
>>
>> Anything there that I can nuke ?
> 
> 	That's an interesting one =) I guess 6.0 is a good substitute for 4.0 -
> I imagine that back-compatibility with some corner-case of pre 3.2
> releases (which were not LibreOffice ;-)
> 
> 	Then again - no idea if there is still a win there; but Stephan is
> really the expert here (?) - quite possibly my comment was wrong ;-)

No idea about the usefulness of that comment regarding class 
dp_misc::PersistentMap (desktop/source/deployment/inc/dp_persmap.h), 
without further investigation.  That PersitentMap appears to wrap 
various potentially existing files ending in .pmap.  While 
registered_packages.pmap 
(desktop/source/deployment/registry/configuration/dp_configuration.cxx) 
might indeed be something obsolete that will not show up for 
sufficiently recent LO (and the code appears to be careful not to create 
one if none exists), at least for me a fresh UserInstallation does 
contain a (non-empty) user/extensions/bundled/extensions.pmap (cf. 
desktop/source/deployment/manager/dp_manager.cxx).