search

streambinder / vpnc

IPsec (Cisco/Juniper) VPN concentrator client
https://davidepucci.it/doc/vpnc
GNU General Public License v2.0
37 stars 20 forks source link

Mutualize maintenance efforts? #14

Closed mdeff closed 3 years ago

mdeff commented 4 years ago

Distributions independently maintain patches for vpnc. Examples:

While Arch uses this repo as the upstream, the others seem to base their patches on the unmaintained original SVN.

As everyone seems to mostly do the same things (e.g., add a systemd service file), it might make sense to ping the maintainers and mutualize maintenance efforts here.

streambinder commented 4 years ago

Sounds good. Will definitely work on this. Thanks.

mdeff commented 4 years ago

Thanks for your work! Looking forward. :)

streambinder commented 4 years ago

Hi @mdeff, as you can see I merged most of patches and custom configurations adopted by distributions: most of them are minor adjustments, but was worth the merge. Do you notice anything missing in there?

mdeff commented 4 years ago

Amazing! LGTM from the Arch side. I've notified the maintainers about the updates so they can update and drop their patches. The last remaining patch in Arch is about vpnc-script (upstream bug).

I don't know enough about vpnc or the other distributions to comment about the rest. I can only hope they'll adopt this repo as upstream, so that we all benefit from everybody's fixes. :)

streambinder commented 4 years ago

About that patch, I thought of merging it but either we use vpnc-scripts from @dwmw2 (and then the patch needs to be applied directly there) or we inject its code and maintain it here (adopting that patch directly). I thought, as the vpnc-scripts code seems to be kept updated, would have been better to stick it as a submodule.

mdeff commented 4 years ago

Agreed. That patch should be merged in @dwmw2's vpnc-scripts.

mdeff commented 4 years ago

@anthraxx is the Arch vpnc maintainer. Maybe they'll have some more thoughts for you. (I'm no packaging expert.)

dwmw2 commented 4 years ago

Other distributions ship vpnc-script in a separate package, and both their openconnect and vpnc packages depend on that.

In OpenConnect we don't have vpnc-script as a submodule; it's just an external dependency (for the CLI mode).

dwmw2 commented 4 years ago

On the topic of mutualising maintenance efforts... it's also severely tempting just to add IKE support to OpenConnect.

mdeff commented 4 years ago

Other distributions ship vpnc-script in a separate package, and both their openconnect and vpnc packages depend on that.

I like this, as it makes the following facts clearer to downstream distro users:

(It was proposed for Arch but not implemented.)

anthraxx commented 4 years ago

Unifying efforts cross distro sounds like a very good idea. Splitting out vpnc-scripts sounds like a good idea as well but note that separate concerns should be opened in separate issues, it simply got overlooked that the side note is an actionable item as well.

However, I'm very displeased to use git submodules for vendoring dependencies in. We try to de-vendor components and provide dependencies via package maintained and controlled/tracked sources and not hidden in vendor folders of repos. This makes it also invisible for the security team once something needs to be addressed if its somewhere deep down the rabbit hole of a vendored folder. So I will be using required adjustments to devendor those components.

streambinder commented 4 years ago

However, I'm very displeased to use git submodules for vendoring dependencies in.

Willing to welcome alternatives: I think incorporating vpnc-scripts is more of a historical line we kept on following. I've no problem in detaching it from this repo, so to clear up the boundaries.

anthraxx commented 4 years ago

However, I'm very displeased to use git submodules for vendoring dependencies in.

Willing to welcome alternatives: I think incorporating vpnc-scripts is more of a historical line we kept on following. I've no problem in detaching it from this repo, so to clear up the boundaries.

maybe have a location where vpnc-scripts is expected? Like /usr/share/vpnc-scripts or similar? The Makefile could have a variable pointing to it that can also simply be overridden when other distros choose a different location for their liking?

mdeff commented 4 years ago

Thanks @anthraxx, it's great to hear from a seasoned maintainer. @streambinder, you might want to invite the other distro maintainers to this discussion table. Their needs should be satisfied for them to adopt this repo as upstream and contribute their future fixes.

streambinder commented 4 years ago

maybe have a location where vpnc-scripts is expected? Like /usr/share/vpnc-scripts or similar? The Makefil could have a variable pointing to it that can also simply be overridden when other distros choose a different location for their liking?

Seems good: https://github.com/streambinder/vpnc/commit/840a05befb518091f70a40673bdc6a825a0f132c.

@streambinder, you might want to invite the other distro maintainers to this discussion table. Their needs should be satisfied for them to adopt this repo as upstream and contribute their future fixes.

Sure: @fschlich (Debian), @SoapGentoo (Gentoo), @ncopa (Alpine), @chkr-private (Fedora), @lnussel (OpenSUSE), @danielg4 (OpenWRT). Hopefully, did not bring in anyone wrong.

dwmw2 commented 4 years ago

cf. http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/configure.ac#l75

I believe that catches all the locations that various Linux, *BSD and other distributions put it.

SoapGentoo commented 4 years ago

Yip, we can do that, thanks for the round table discussions :+1:

anthraxx commented 4 years ago

that looks great and modular :+1:

SoapGentoo commented 4 years ago

@streambinder would you entertain going to something more "vanilla" for the build system? In general using a simple Autotools, CMake or Meson based buildsystem would help us, because most distros have hooks for these, and most maintainers prefer one of these over homebrew Makefiles with lots of idiosyncrasies. But I'm fully aware that this is a contentious topic.

anthraxx commented 4 years ago

please no cmake, its simply a broken build system that doesn't even respect CPPFLAGS for solid 9 years since it has been reported and distros need to work around it for proper protection like fortified sources.

SoapGentoo commented 4 years ago

Autotools/Meson both respect CPPFLAGS just fine FYI

dwmw2 commented 4 years ago

Much as I hate autotools and avoided them for years, I'd strongly recommend them over cmake, meson, or whatever next year's fad is. They are reliable, portable and effective.

I've rarely been told I have to upgrade my version of autotools just to build a project, while that seems to be common for cmake and meson — they're just another barrier to portability, which means they're having precisely the opposite of the effect they were intended to have.

streambinder commented 4 years ago

Would you entertain going to something more "vanilla" for the build system? [...]

Please no cmake [...]

Much as I hate autotools and avoided them for years, I'd strongly recommend them over cmake, meson, or whatever next year's fad is. They are reliable, portable and effective. [...]

I want to take a stand in defense of make. While it is true I just thought to stick to the original build mechanism (given the nature of this fork) without even questioning myself on a possible project revamping, I think that make stays as old and rustic (is there actually anything more vanilla than that?), as well as widely supported and acknowledged. And given the already emerging different points of view on this regard, I'd rather stick to the current line.

streambinder commented 4 years ago

Further on the discussion, I'd like to move the topic to the original point: all the maintainers of the most widely used distributions should be here. As @mdeff originally pointed out, it'd be cool to make this project moving in the direction and along with the needs of users (and the distributions on which they rely). Looking around at all the work you've done packaging it, I tried to pull in as much as possible and we dragged you all in to partecipate in the progress: given the current state of the project, do you feel like there's something missing? Do you think this project still needs to be shipping with specific stuff in, rather than merging you afterwards at the packaging phase?

SoapGentoo commented 4 years ago

The problem is, every handwritten Makefile is horrible in its own way. Here are four:

  1. The current Makefile isn't a proper Makefile, it's actually a GNUmakefile (ifeq and friends). That means it automatically doesn't work on vanilla BSD and requires GNU make. Automake enforces Makefile portability. You can't workaround this in general, as portable branches in Makefiles are impossible.
  2. The current setup doesn't allow for building out of source, which we often do in Gentoo, and something that is pointlessly hard to do without Automake.
  3. The current setup doesn't lend itself to cross-compilation. Case in point: while pkg-config is being used, it isn't being indirected on a PKG_CONFIG variable (which is generally necessary to point to which pkg-config you're using for cross compilation). While this can be added of course, it's more and more boilerplate that Automake/Autoconf handle for you.
  4. Automake's make distcheck checks that you can build out-of-source and that all files are being properly included and are at the right location and unit tests pass. It makes packaging so much easier.

Yes, I believe using a standardized build system like Autotools would be a great help, and I'm sure most of the other distro maintainers will agree. It means I can remove all the extra code I need to downstream to install unit files and stuff.

streambinder commented 4 years ago

I never thought your reasons were questionable, but along with standards, you're speaking on behalf of Gentoo. The project - hence, this issue - is not inherently meant to help packagers and maintainers to ship it in the corresponding distributions. On the other end, cooperation is encouraged and a case like yours, if shown to be common to most of the other maintainers, would be surely welcome.

lnussel commented 4 years ago

openSUSE doesn't seem to have a dedicated package maintainer so I'm not the maintainer :-) My name may show up in some records as I was release manager for some time. AFAICT the package is just kept building by random people that fix build failures all across the distro. So in case the openSUSE package contains anything useful feel free to pick it up. There's just one patch in there though: https://build.opensuse.org/package/show/openSUSE:Factory/vpnc

streambinder commented 4 years ago

Ok, thank you. That patch has been already merged.

streambinder commented 3 years ago

Alright, this issue has been kept open for quite a long time to allow maintainers and contributors to bring in issues related to distributions packaging. As it's been quite a while since no one has brought up a suggestion or a specific need, I'd rather close it.

@SoapGentoo, if you really feel that switching to autotools represents a shared need and plus for the project, feel free to make a PR that I'd be glad to merge. Of course, if anybody is explicitly against it, feel free to say it.

Thanks everybody, and @mdeff for bringing up this in the first place.