Opened 3 years ago

Closed 15 months ago

#268 closed task (fixed)

Packaging requirements for 1.4.0

Reported by: lewisr Owned by:
Priority: major Milestone: 1.4.0
Component: Packaging Version: 1.3.5
Keywords: Cc:


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

Change History (5)

comment:1 Changed 3 years ago by gyoung

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.

comment:2 Changed 3 years ago by gyoung

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.

comment:3 Changed 3 years ago by lewisr

Need to check/set the following new env vars during install (ref #324):


More responses and ideas coming in separate comments.

Last edited 3 years ago by lewisr (previous) (diff)

comment:4 Changed 2 years ago by lewisr

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

comment:5 Changed 15 months ago by lewisr

  • Resolution set to fixed
  • Status changed from new to closed

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

Note: See TracTickets for help on using tickets.