Suricata

What problem does this patch solve?

The way setup.py --prefix is used it forces the site-packages directory to be installed in a location that is potentially different than where python's default site-packages directory is.

For instance if you compile suricata with --prefix of /opt/suricata then the site packages will be /opt/suricata/lib/python3.7/site-packages instead of the expected /usr/local/lib/python3.7/site-packages that python is expecting. Without the path you will need to do more work to set the python environment up in order to use suricata-update or any of the other python utilities.

My patch uses setup.py --root instead which will put the python libraries within the "correct" site-packages location while still allowing the executable scripts to be installed in the --prefix for suricata.

The way we do it now is on purpose.

With this patch what happens if I install 4.1.5 with --prefix=/opt/suricata-4.1.5 and 5.0.0 with --prefix=/opt/suricata-5.0.0? Will one not overwrite the others Python support files?

Suricata-Update and the other python tools that ship with Suricata should handle this case just fine. If they don't, the specific tool should be fixed up to pickup its associated Python modules.

I should have probably prefaced this with the information that I am a package builder. In my situation there can only be one instance installed at a time. I acknowledge that my situation is directly at odds with hand builds that developers do.

Shawn Michael wrote:

I should have probably prefaced this with the information that I am a package builder. In my situation there can only be one instance installed at a time. I acknowledge that my situation is directly at odds with hand builds that developers do.

What are you building packages for? Fedora seems to use us as-is. I think Debian doesn't use the bundled suricata-update, but builds it from its own release which could be used.

In house corporate package maintainer. We have a CentOS base, but have a few items upgraded that would conflict with CentOS packages if we placed them in the "correct" location with respect to the distribution. Python 3.7 is one of those upgraded packages (we have an independent requirement for it to be available as "python" not "python37"). So it's PATH manipulation for us to get the right thing called in the right situation. Luckily for us yum uses #!/usr/bin/python and not #!/usr/bin/env python so it just happens to work in our situation.

Both Fedora and Debian will be using the "system" python and both will use their standard package location prefix (/usr). So normal distribution packagers just happen to work with what you choices. I'm in the "value added" space and build upon others work, which results in some doing some work arounds some classes of problems. This is one.

To me this is a bug in my narrow view of the world. To upstream distribution maintainers what you have likely works just fine (the prefixes are the same). For suricata developers and multi-version evaluation on a single box, my patch is directly at odds with ease of use in those narrow situations. I proposed the patch as a fix for my world view, you enlightened me on your needs as developer which conflicts on the ease of use in my situation.

I acknowledge that my world view may be an extreme minority type situation. Ease of use for developers may trump how I think things should be. I am independently maintaining this patch for our in house use. In my case submitting to upstream is a possible selfish way for less work for me in the long term if what I provided is useful.