Package Details: inspircd 3.17.1-2

Git Clone URL: https://aur.archlinux.org/inspircd.git (read-only, click to copy)
Package Base: inspircd
Description: InspIRCd is a modular Internet Relay Chat (IRC) server written in C++ for Linux, BSD, Windows and macOS systems.
Upstream URL: https://www.inspircd.org/
Licenses: GPL2
Conflicts: inspircd
Provides: inspircd
Submitter: Max-P
Maintainer: Max-P
Last Packager: Max-P
Votes: 11
Popularity: 0.000351
First Submitted: 2015-12-01 03:57 (UTC)
Last Updated: 2024-06-29 23:31 (UTC)

Dependencies (28)

Required by (2)

Sources (3)

Latest Comments

1 2 3 4 Next › Last »

Max-P commented on 2024-06-30 00:12 (UTC)

@xiota Look at the 4.0.0 breaking changes, that's like 13 of them. From this package that's 2-3 of the regex modules and mbedtls support.

The problem I see is upstream seems to intend people to have the build artifacts around to just build out of tree modules in-tree via a shell script. I'm also assuming those modules will now be maintained somewhat separately from the base package, which could make versioning a pain. I could just... build everything in a single package but I feel like there's already a lot of bloat and unnecessary dependencies. For example you need MySQL and PostgreSQL installed to build this even if you'll never use those modules. Or I could at least build the existing modules this ships to maintain feature parity.

I think in an ideal world I'd ship headers with inspircd and then have a split package for inspircd-contrib-git that spits out a package for every module, and a PKGBUILD template for how to build custom third-party modules not in contrib. I could also just make them all individual packages but then you're gonna git clone the repo like 40 times. I'm trying to think of both users that will build those on their IRC server and those that use aurutils and make a custom repo for the servers.

xiota commented on 2024-06-29 23:45 (UTC)

@Max-P How many modules? Are they tightly coupled with cross depends? If so, I would try to keep them together in the same PKGBUILD. I would also avoid split packaging if benefit does not significantly outweigh increased complexity. Look at aur/flutter for how complicated and confusing split packaging can be. (The pinned comment even lacks key info needed to build successfully.)

Max-P commented on 2024-06-29 23:36 (UTC)

Updating to 3.17.1 for now but 4.0.0 is on my radar. A bunch of modules that are currently bundled with this package have been moved to external modules in inspircd-contrib. I need to figure out what's the best way to build and package those, either as optional parts of the build or as separate packages. I'm open to suggestions.

xiota commented on 2023-05-13 23:34 (UTC) (edited on 2023-05-14 12:56 (UTC) by xiota)

Thanks for updating. ArchWiki has this article, DeveloperWiki:Building in a clean chroot. In short, extra-x86_64-build will build in a clean chroot. Building packages with other AUR dependencies takes more effort.

Max-P commented on 2023-05-13 22:49 (UTC)

@xiota: yes, I just added it. I just needed to find a minute to update the package and test build it. I wouldn't mind setting myself up with clean chroots to catch those issues in the future.

This package could use a bit of a cleanup to be honest, if you have any more suggestions let me know. When I adopted this package, there were a bunch of configurable flags to only build what you wanted which doesn't work well when packaging for repos, it should build everything by default and rely on optdepends.

xiota commented on 2023-05-12 03:47 (UTC) (edited on 2023-05-14 12:55 (UTC) by xiota)

Adding pcre to makedepends does allow build to continue past that point. Required to build in a clean chroot.

Max-P commented on 2023-05-12 02:49 (UTC)

@xiota: Does adding pcre to the makedepends resolve it for you?

pcre-config comes from core/pcre, but on my machine that command returns nothing and a status of 0.

1 2 3 4 Next › Last »