On Thu, Nov 13, 2014 at 04:36:09PM +0100, Gilles Chehade wrote: > On Thu, Nov 13, 2014 at 03:59:19PM +0100, Emmanuel Vadot wrote: > > > > Hello list, > > > > Currently the build system for the extras (table, filters etc ...) is not > > really intelligent. > > It does not check is the required libs or interpreters in present on the > > machine and doesn't even use the correct path for the libs. > > This is a problem for user and packagers since now it's not possible to > > easily provide an OpenSMTPD package with mysql for example. > > > > After talking to gilles@ in private on IRC we tought on possibly make the > > following changes : > > > > 1) Each extras will provides it's own configure script > > 2) Each configure scripts will correctly check its dependancies > > 3) All extras will be shipped in a single archive > > 4) Maybe have just one branch in the git since OpenBSD doesn't ship with > > smtpd extras. > > > > For 1, it will simply keep the configure as simple as it need to be > > > > For 2, well ... > > > > For 3, I know that the FreeBSD ports infrastructures can handle this > > correctly (having multiple ports that depends on one distfiles, the Qt > > ports for plugins does that). Is there some ports/packages infrastructure > > that can't ? > > > > To make it more clear, right now people tend to clone / fetch the entire > extras just to grab that one bit they need. > > The idea is to make each extra individual so that while they are all in > the same repository, one can package a specific extra for his system so > ultimately you can: pkg_add opensmtpd-filter-dkim, ... > > [...] > > At the moment, extras are not correctly integrated, it took us quite some > effort to split them out of the smtpd tree but we have not yet worked on > how to "easily" plug them. > > What I suggested with regard to the "just one branch" idea, is the > following: > > smtpd is developed on OpenBSD and "fixed" for portability using the > compat glue, so we need two branches to avoid the compat glue ending > in the openbsd tree where it's not needed. > > -extras are different: they are developped on different systems by > non-openbsd developers, they can have any dependencies and are supposed > to be the same code on OpenBSD and other systems are they communicate > with smtpd through a common API. > > therefore my idea was to drop the master/portable difference for extras > and have a single branch for both. >
ok, so work has officially started in this area. Tonight I will focus on merging the portable and master branch together, then later the autotools glue will be added appropriately. One idea stepped in my mind and I would like to know what you guys think about it: There is currently no separation between extras that are considered prod ready and extras that are considered work in progress. Also, some of the extras which are considered prod ready are undocumented which isn't good and not to our standards. I suggest that we add a wip/ directory in -extras with the same layout and while we accept all contributions to wip/, only those documented and production ready gets moved out of wip/ what do you think ? -- Gilles Chehade https://www.poolp.org @poolpOrg -- You received this mail because you are subscribed to [email protected] To unsubscribe, send a mail to: [email protected]
