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.
]]>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.
]]>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.
]]>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.
]]>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.
]]>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.
]]>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?
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?
]]>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.
]]>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
]]>