[SOLVED] How to handle multiple configuration options?

pgoetz · 2019-03-09 22:55:59

I'm working on refreshing the cyrus-imapd AUR package I inherited a while back, and in looking over the configuration options

./config

there are a number of different ways to go. For example

With or without Kerberos support
With or without LDAP support
With or without mysql support
With or without CalDAV/CardDAV support
With or without Murder support
With or without support for Replication

Taking just the example of Murder, if you need it, you really need it, but most IMAP servers are not going to need it. Ideally, I'd like to have a preinstall script which asks the user which options they care about and then set build() flags accordingly, but I"m not sure it's possible to do this in PKGBUILD?

Any suggestions on the best way to proceed? This suffers from something of a combinatorial explosion problem, so just having a different package for each possible configuration is neither practical nor elegant. I couldn't find anything on the Creating Packages Wiki page. The LXD AUR package asks you which version of LXD you want to install, but I'm not sure how they do this; it doesn't seem to be in the PKGBUILD.

Last edited by pgoetz (2019-03-12 19:30:58)

Trilby · 2019-03-09 23:10:14

A PKGBUILD should build the same package regardless of where it is used. This is a rule that is occasionally violated by checking for a user-provided config file. A PKGBUILD should never be interactive. This is a rule that should never be broken. Period.

I'd suggest going the route of dwm, st, or other suckless tools. It is an AUR package, so user's will have to build their own regardless - so just provide instructions to users on how they can make configuration changes at compile time.

loqs · 2019-03-10 01:40:12

Have you thought about starting with easier updates to the package such as always quoting srcdir and pkgdir,
updating the install file so it does not create or remove users/groups use sysusers.d similarly instead of creating / modifying files/directories use tmpfiles.d or
adding a pam config https://bugs.archlinux.org/task/61712
Edit:
updating to the latest stable version (3.08) (also consider switching to http(s) from ftp)
using the gpg signature for tar.gz and adding a validpgpkeys entry

Last edited by loqs (2019-03-10 21:42:41)

pgoetz · 2019-03-12 13:11:44

Trilby wrote:

I'd suggest going the route of dwm, st, or other suckless tools. It is an AUR package, so user's will have to build their own regardless - so just provide instructions to users on how they can make configuration changes at compile time.

The dwm and st AUR packages include a config.h file which is copied into the $srcdir/$pkgname-$pkgver directory prior to the build process (neither of these includes a configuration step). I think what you're suggesting is to include the configuration command line options as a file and then provide users with instructions for editing this file? That might work, with the default configuration set to the presumed most common options.

Now I need to figure out how to create a pre-install script. Is this documented somewhere? I remember reading about in the devel notices, but couldn't find anything on the Creating Packages

pgoetz · 2019-03-12 13:16:57

loqs wrote:

Have you thought about starting with easier updates to the package such as always quoting srcdir and pkgdir,

Another Arch user tried doing this, creating an AUR package called cyrus-imapd-new, but I can't get this package to build. Quite a lot has changed in cyrus between versions 2.x and 3.x; an extensive update to the AUR package is warranted.

To give just one example, as far as i can tell the old PKGBUILD would not have allowed admins to use virtual email domains because support for a database backend is now a configuration step option.

Trilby · 2019-03-12 13:17:28

For a file with a list of configure flags, I'd just call that a PKGBUILD. User's can modify the PKGBUILD. Just comment each relevant configure flag so user's can decide what to include and what not to include.

For the install script, that's clearly covered in the wiki:
https://wiki.archlinux.org/index.php/PKGBUILD#install

But why do you need a pre-install script? Would a hook work? Is this related to the topic of this thread, or is this a new question?

Last edited by Trilby (2019-03-12 13:20:21)

Lone_Wolf · 2019-03-12 13:19:33

edit : to slow

Last edited by Lone_Wolf (2019-03-12 13:20:29)

loqs · 2019-03-12 15:30:38

pgoetz wrote:

loqs wrote:
Have you thought about starting with easier updates to the package such as always quoting srcdir and pkgdir,
Another Arch user tried doing this, creating an AUR package called cyrus-imapd-new, but I can't get this package to build. Quite a lot has changed in cyrus between versions 2.x and 3.x; an extensive update to the AUR package is warranted.

cyrus-imapd-new builds for me in a clean chroot.
cyrus-imapd the ftp server appears down and the path used if the server was up appears to be for the latest release of each series only. After changing the source address builds in a clean chroot.
What is the advantage in using the cyrus-imapd PKGBUILD as the base for your changes over cyrus-imapd-new?

pgoetz · 2019-03-12 15:46:38

Trilby wrote:

But why do you need a pre-install script? Would a hook work? Is this related to the topic of this thread, or is this a new question?

It's related to your suggestion: if I'm going to afford users the option of streamlining (or beefing up) the software configuration, then I probably need to let them know at the beginning of the package building process.

Thanks for the link to the pre/post install script syntax. Not sure how I overlooked this on first reading. However, it seems to me that entire section would make more sense on the Creating Packages Wiki page rather than the PKGBUILD page.

A hook wouldn't make sense in this context as this has to do with pre-compilation issues and Hooks appear to be intended to trigger system modifications based on package installation or removal.

pgoetz · 2019-03-12 16:04:58

loqs wrote:

cyrus-imapd-new builds for me in a clean chroot.
cyrus-imapd the ftp server appears down and the path used if the server was up appears to be for the latest release of each series only. After changing the source address builds in a clean chroot.
What is the advantage in using the cyrus-imapd PKGBUILD as the base for your changes over cyrus-imapd-new?

None, but then they're nearly identical, and I'm looking at both.

Regarding getting it to build: when I try, it has no problem finding the source, but the package construction process crashes here:

make[2]: Leaving directory '/usr/local/src/aur/cyrus-imapd-new/src/cyrus-imapd-3.0.8/perl/sieve/managesieve'
make[1]: Leaving directory '/usr/local/src/aur/cyrus-imapd-new/src/cyrus-imapd-3.0.8'
install: cannot stat '/usr/local/src/aur/cyrus-imapd-new/src/cyrus-imapd-3.0.8/master/conf/normal.conf': No such file or directory
==> ERROR: A failure occurred in package().
    Aborting...

The config() section in the cyrus-imapd-new PKGBUILD file is identical to the config() in cyrus-imapd, which is for version 2.5.10 of cyrus-imapd. Looking through the cyrus documentation, the configuration options appear to have changed for version 3.x, so need to be updated.

Thanks for your suggestions! I realized that I need to do due diligence by updating the current cyrus-imapd to 2.5.12, which wasn't released that long ago. If this still works on Arch, it probably should continue to be maintained for existing installations that don't want to suffer a major upgrade.

Last edited by pgoetz (2019-03-12 16:05:42)

loqs · 2019-03-12 16:07:26

I would suggest requesting a rename then to cyrus-imapd-2.5 as you are not tracking the latest release.
Edit:
Did you try moving the local copy of the source to a different location before testing the PKGBUILD?
Edit2:
cyrus-imapd-new fails to build in a clean chroot ~~missing makedepends pkgconf and~~ missing depends jansson after those changes I see the packaging issue you encountered.

Last edited by loqs (2019-03-12 17:37:05)

pgoetz · 2019-03-12 16:23:46

loqs wrote:

I would suggest requesting a rename then to cyrus-imapd-2.5 as you are not tracking the latest release.

So, another good suggestion. I'll attempt to build 2.5.12, and if this runs on my newly updated Arch server which already has cyrus-imapd installed, rename this package to cyrus-imapd-2.5 and then switch cyrus-imapd to the 3.x series, which also needs some work, as you've observed.

Trilby · 2019-03-12 17:07:58

pgoetz wrote:

if I'm going to afford users the option of streamlining (or beefing up) the software configuration, then I probably need to let them know at the beginning of the package building process.

Then install scripts are not relevant. A pre-install script becomes part of the built package and is executed before the installation (hence the name), not before the package is built.

Put a comment in the PKGBUILD and/or in the comments section of the AUR. Nothing more should be needed. And nothing more could work: any script that would nanny the user through this stage would have to be run when they download the PKGBUILD, not when they build the package.

You could echo a message from the prepare or build function to inform the user that they can edit the PKGBUILD and rerun makepkg with other config options - but this is already a given, this is always an option. What you can do is just nicely comment the configure options in the PKGBUILD making it easy to add/remove the relevant flags.

In the build function, you could have the following:

   ./configure \
   --always-needed-flag \
   --other-flag-everyone-wants \
   ## If you need virtual email domains uncomment the following two lines
   # --with-something-needed \
   # --with-other-thing \
   ## If you need Murder, uncomment the next line
   # --dial-M \
   ## If you don't need imap umap comment the following line
   --imap-umap-we-all-map-for-imap

If a "sysadmin" can't read and edit a PKGBUILD before building an AUR package, they have much bigger problems.

Last edited by Trilby (2019-03-12 17:14:11)

pgoetz · 2019-03-12 19:30:35

Trilby wrote:

If a "sysadmin" can't read and edit a PKGBUILD before building an AUR package, they have much bigger problems.

Thanks for your help with this. Your suggestion seems reasonable. the lxd AUR package includes this helpful post_install script:

[pgoetz@frog lxd]$ cat lxd.install 
post_install() {
    getent group lxd || groupadd lxd
    echo "LXD allows everyone in the lxd group to talk to LXD."
    echo ""
    echo "LXD needs sub{u,g}ids for root, so that it can create unprivileged containers."
    echo "Execute the following to set the sub{u,g}ids:"
    echo "'echo \"root:1000000:65536\" | sudo tee -a /etc/subuid /etc/subgid'"
}

Although this is a perfect example of what a hook should be used for.

In the interim I checked with one of the cyrus-imapd developers who thought there weren't really any downsides to compiling a single monolithic cyrus executable with all functionality available, so I'll make that the default and maybe add a comment that people who want to streamline can remove certain configuration options. One tiny complication is that some of the configuration options create additional package dependencies, but I'll put these commented in the optional dependencies list and maybe include some verbiage reminding people that if they want, for example, to use CalDAV they'll also need to install libical and libxml.

Marking this post as solved.

Trilby · 2019-03-13 00:02:49

pgoetz wrote:

The lxd AUR package includes this helpful post_install script...

Yes, but that actually is post-install information. While recent changes would favor using systemd to create that group, what that package does was previously advisable. However, that post_install script doesn't have any relevance to compile-time configuration options.

loqs · 2019-03-17 20:59:47

https://lists.archlinux.org/pipermail/a … 30372.html as the cyrus-imapd package was not updated by pgoetz https://lists.archlinux.org/pipermail/a … 30373.html

Last edited by loqs (2019-03-17 21:00:20)

pgoetz · 2019-03-17 21:02:47

Yep; someone took over the package before I could finish rebuilding it, and probably did a better job than I could have.

Arch Linux

#1 2019-03-09 22:55:59

[SOLVED] How to handle multiple configuration options?

#2 2019-03-09 23:10:14

Re: [SOLVED] How to handle multiple configuration options?

#3 2019-03-10 01:40:12

Re: [SOLVED] How to handle multiple configuration options?

#4 2019-03-12 13:11:44

Re: [SOLVED] How to handle multiple configuration options?

#5 2019-03-12 13:16:57

Re: [SOLVED] How to handle multiple configuration options?

#6 2019-03-12 13:17:28

Re: [SOLVED] How to handle multiple configuration options?

#7 2019-03-12 13:19:33

Re: [SOLVED] How to handle multiple configuration options?

#8 2019-03-12 15:30:38

Re: [SOLVED] How to handle multiple configuration options?

#9 2019-03-12 15:46:38

Re: [SOLVED] How to handle multiple configuration options?

#10 2019-03-12 16:04:58

Re: [SOLVED] How to handle multiple configuration options?

#11 2019-03-12 16:07:26

Re: [SOLVED] How to handle multiple configuration options?

#12 2019-03-12 16:23:46

Re: [SOLVED] How to handle multiple configuration options?

#13 2019-03-12 17:07:58

Re: [SOLVED] How to handle multiple configuration options?

#14 2019-03-12 19:30:35

Re: [SOLVED] How to handle multiple configuration options?

#15 2019-03-13 00:02:49

Re: [SOLVED] How to handle multiple configuration options?

#16 2019-03-17 20:59:47

Re: [SOLVED] How to handle multiple configuration options?

#17 2019-03-17 21:02:47

Re: [SOLVED] How to handle multiple configuration options?

Board footer