Packaging requirements for 1.4.0

[Lewis Rosenthal]

Now that we are no longer using a static poppler, we have to determine the best course of action during install. For pdf rendering, we now require the poppler library to be installed. This is normally done via yum.

If we continue to package Lucide as WPI, this requires either a readme entry, a check during install, or an external call to yum during WarpIN install to ensure that poppler is on the system.

If we now package as RPM, of course, poppler would simply become a prerequisite.

Finally, we could package without plugins, and package plugins separately (though we still must decide on the best packaging method to use for each plugin).

[Gregg Young]

From Ticket #303

Is there a way with yum/rpm to install a plugin in the lucide directory (ie using an environment variable)? Can it use the presence of this variable to identify the dependency? If so and we can't find a solution to rebuilding, we could just package the plugins and update the lucide install with the new plugin when the lib is updated. We could redesign the warpin so when updating lucide installing each plugin is optional so if someone doesn't want to install the latest lib they simply keep their old plugin. The warpin would add the environment variable on initial install or on update from 1.3.5 or older. This would mean building the plugins against at least some older versions of the libs to prevent lucide from being broken if someone back levels the lib.

End from ticket #303

It might also be wise to put the plugins from 1.3.5 in a subdirectory so someone could easily revert to them if they get the plugins and libs out of sync and can't resync them as indicated in ticket #297 where the reporter couldn't get ANPM to back level poppler.

[Gregg Young]

We should be able to include REXX scripts that check for the appropriate dll (ie popple63.dll) in the warpin. We would use these to disable install of the plugin that needs the dll and give a message telling the user they need to install a different version of the lib if they wish to use this plugin. I am not sure this functionality exists but it would sure be nice.

[Lewis Rosenthal]

Need to check/set the following new env vars during install:

• LUCIDEINSTALLPATH
• LUCIDEHELP

More responses and ideas coming in separate comments.

[Lewis Rosenthal]

Language packs need to go into separate WPI files. I have five additional language selections to make during setup, but after adding the third, the WIS gets too long, leading to errors with the installation (though wic -t does not complain). (Thanks to Paul R for pointing out to me that the WIS needs to be put on a diet.)

[Lewis Rosenthal]

Resolving this. If we have specific changes for the next version's packaging, we should create a fresh ticket.