[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: about build flavours



Hi Raphael,

thanks, here are a few more thoughts.

>> Currently, our main idea is to create a suricata-hyperscan package
>> which includes the dependency to hyperscan, and the binary is build
>> linked to the library.
>>
>> We distribute two /usr/bin/suricata binaries in two binary packages:
>>  * suricata, without hyperscan
>>  * suricata-hyperscan, with hyperscan
>>
>> Then, we conflict the packages with each other and dpkg-divert the
>> /usr/bin/suricata file in suricata-hyperscan.
> 
> If both packages conflict with each other, then you don't need
> dpkg-divert. 

One could think of multiple approaches with varying modularity.

The first approach builds two full copies of the suricata package with
all package contents in each, largely identical except for
/usr/bin/suricata which differs w.r.t. Hyperscan support compiled in
(and dependencies, obviously). These two packages would indeed be set to
Conflict: with each other to avoid file clashes.

In the other (IMHO better) approach one wouldn't set Conflicts. The idea
is to have an original suricata package containing everything including
a generic /usr/bin/suricata binary without Hyperscan support. This file
would get dpkg-diverted via the suricata-hyperscan package by a version
of this file that has Hyperscan support.
In this case the suricata-hyperscan package would only contain
/usr/bin/suricata to reduce duplication of content. It would depend on
libhyperscan4 (as it should) as well as on the original suricata
package, to make sure the 'rest' of the Suricata distribution is
installed. This way one could 'patch' Hyperscan support in by just
installing suricata-hyperscan.

At least these are the two alternatives linked in #846143.

> And dpkg-divert is mainly useful when you want to replace a
> file that is not under your own control, otherwise using the alternatives
> system is usually preferred.

Interesting. I assume this would require using unique installation paths
for both the Hyperscan-enabled and non-enabled /usr/bin/suricata
versions, neither of which should be /usr/bin/suricata?

Cheers
Sascha

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: