<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:DengXian;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"\@DengXian";
panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-AU link="#0563C1" vlink="#954F72" style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>Hey all,<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>What do people think about creating a “koha-libs” package which just contains Koha’s libraries (ie C4/, Koha/, etc)?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I’m not as familiar with DEB packaging as I am with RPM packaging, but I recently did it with a RPM-based project I manage. It allowed me to easily create other services with the same dependencies. I created these other services in other Docker containers, and I was able to use my core application libraries without having to install the entire application in every container. I share the application configuration file between them and that’s it. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>It’s not a perfect solution. Really what I want is app-service1, app-service2, app-service3, and app-common with app-common containing the shared libraries. But I like it as an intermediate step. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>And I would be lying if it didn’t have pros and cons. One con is updating a library in app-libs, when I need a change in app-service1, and then making sure that all my deployments have the right updated library. More overhead than just having a monolithic application. On the other hand, if I want to make a change just to app-service1, I can just update it without having to affect any other parts of the application. That added overhead also gives incentive for writing cleaner testable code which does the right thing in the first place. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Anyway, just food for thought. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>David Cook<o:p></o:p></p><p class=MsoNormal>Software Engineer<o:p></o:p></p><p class=MsoNormal>Prosentient Systems<o:p></o:p></p><p class=MsoNormal>Suite 7.03<o:p></o:p></p><p class=MsoNormal>6a Glen St<o:p></o:p></p><p class=MsoNormal>Milsons Point NSW 2061<o:p></o:p></p><p class=MsoNormal>Australia<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Office: 02 9212 0899<o:p></o:p></p><p class=MsoNormal>Online: 02 8005 0595<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>