[SOLVED] New PKGBUILD critiques needed.

SonOfANoMomGoat · 2015-08-10 02:55:49

I'm handling the PKGBUILD for a devel branch of a package already on the AUR at https://aur4.archlinux.org/packages/rpimonitor.

I have the two main config files set for backup, but within the package there is a directory /etc/rpimonitord/templates that contains conf files that need to be minded. What would be the Arch way to handle this issue? Notify the user with the install scriptlet during pre-upgrade to manually backup the files?

Here is the PKGBUILD:

# Maintainer: Dan Schaper ( dschaper at ganymeade dot com)
# Contributor: ajs124 < aur AT ajs124 DOT de >

pkgname=rpimonitor-dev-git
_pkgbase=rpimonitor
pkgdesc="A self monitoring application designed to run on Raspberry Pi. Development branch."
arch=('armv6h' 'armv7h')
license=('GPL')
pkgver=2.10.r42.g4a98731
pkgrel=1
depends=(rrdtool perl-http-daemon perl-json perl-ipc-sharelite perl-file-which)
makedepends=('git')
url=(https://github.com/XavierBerger/RPi-Monitor)
source=($pkgname::git://github.com/XavierBerger/RPi-Monitor.git#branch=devel)
sha512sums=('SKIP')
backup=('etc/rpimonitor/data.conf' 'etc/rpimonitor/daemon.conf')
conflicts=('rpimonitor')

pkgver() {
  cd "$pkgname"
  git describe --long --tags | sed 's/^v//;s/\([^-]*-g\)/r\1/;s/-/./g'
}

prepare() {
  cd "$pkgname"/${_pkgbase}
  rm data.conf
  ln -s ./template/arch.conf data.conf
  cat daemon.conf data.conf > rpimonitord.conf
  ../tools/conf2man.pl ./rpimonitord.conf ${pkgver} | gzip -c > rpimonitord.conf.5.gz
  ../tools/help2man.pl ./rpimonitord ${pkgver} | gzip -c > rpimonitord.1.gz
}

package() {
  cd ${pkgname}/${_pkgbase}
  install -Dm755 -t ${pkgdir}/usr/bin/ ${_pkgbase}d
  install -Dm644 -t ${pkgdir}/etc/$_pkgbase/ *.conf
  install -Dm644 -t ${pkgdir}/etc/$_pkgbase/template ./template/*
  install -Dm644 -t ${pkgdir}/usr/lib/systemd/system/ ../tools/systemd/*
  install -Dm644 -t ${pkgdir}/var/lib/rpimonitor/ updatestatus.txt
  install -Dm755 -t ${pkgdir}/usr/share/${_pkgbase}/scripts ../scripts/*.pl
  cp -a web ${pkgdir}/usr/share/${_pkgbase}/
  install -Dm644 -t ${pkgdir}/usr/share/man/man1 ${_pkgbase}d.1.gz
  install -Dm644 -t ${pkgdir}/usr/share/man/man5 ${_pkgbase}d.conf.5.gz
}

Last edited by SonOfANoMomGoat (2015-08-25 08:32:07)

thiagowfx · 2015-08-10 04:56:53

What do you mean by "that need to be minded"?

Do they need to be updated? If yes, then the answer probably lies in the use of .pacnew files, I believe. You don't create those files: actually, after an upgrade, a /etc/rpimonitor/templates/example file would be replaced by a new one, thus the old one would be renamed to /etc/rpimonitor/templates/example.pacnew. However, I don't remember how to make use of this feature, but it might be a starting point for your searches through the wiki. I *think* the backup array in the PKGBUILD handles this.

SonOfANoMomGoat · 2015-08-10 13:25:19

The directory /etc/rpimonitor/template is created by the PKG and that directory stores a number of .conf files that would be edited by the user to fit their needs. The defaults for those files are also installed by the PKG. I couldn't find a way to keep those files from being overwritten as I didn't find a way to add an entire directory to the backup array. I will look to see how and when .pacnew files are created, thank you for that lead.

I'm also concerned about using `install -t` instead of creating the directories with `install -d` and then `install -D` the files, as the PKGBUILD's I have looked at seem to use `install -d` instead of the reversed `install -t`. And should I explicitly `cd` to the sourcedir and pkgdir or rely on the fact that `makepkg` automatically moves to those directories?

progandy · 2015-08-10 16:41:29

You can always rely on the fact that prepare, build, and package (and package_foo) start out in $srcdir.

For the template directory, I suggest you don't include it in the backup array. It is so aptly named "template". I rather think it would be wise to copy the files to another location and modify them there. Still, if you really want pacnew files for them, list them manually or generate the backup array in the package function with a globbing loop.

Last edited by progandy (2015-08-10 16:46:19)

SonOfANoMomGoat · 2015-08-10 18:01:55

I personally like the idea of moving the files, however the application itself requires the files to be in that directory, as it reads the files from that directory to build it's store of rrd's that make up the basis of the application. I didn't know you could use loops in the backup array, I will need to check that out, thank you for the tips.

progandy · 2015-08-10 18:12:48

SonOfANoMomGoat wrote:

I personally like the idea of moving the files, however the application itself requires the files to be in that directory, as it reads the files from that directory to build it's store of rrd's that make up the basis of the application. I didn't know you could use loops in the backup array, I will need to check that out, thank you for the tips.

Using loops should work when building the package, but I think it won't be added in a .SRCINFO. Since the backup-array is unimportant for the AUR, that doesn't matter I think.

SonOfANoMomGoat · 2015-08-11 02:08:33

The template directory contains about 20 files to start with plus whatever files the user adds after installation. I'm not sure the globbing loop with work, at least it would be an unsightly beast. I'm leaning towards a big echo statement in the install file that warns the user to make sure they have that directory backed up before moving on. (I'm only approaching the subject because the release package has comments that users were complaining about losing configurations...)

Should this package even be in the AUR since it is more of an ALARM package (it's made for Raspberry Pi's so it's really ARM only, no x86's) I am trying to use the lessons I'm learning here to make my other packages that do belong in the AUR better however.

severach · 2015-08-11 04:01:55

Read the 'HANDLING CONFIG FILES' section in the pacman man page. It may be that backup does what you want.

If backup doesn't suit your needs it's easy enough to manage the configs yourself. In some of my packages I install all the config files as .default files. In post_install via post_upgrade I copy them to their proper names. In pre_upgrade I delete the ones that md5sum says are the same as the .default files and post_upgrade copies the new ones. The PKGBUILD names each file explicitly. The installer just does:

local file
for _file in *.default; do

My biggest bug with backup is that I don't like the .pacsave files on remove and some packages must be uninstalled only to reinstall. The solution is to make the installer .pacsave aware. A little code in post_install brings the .pacsave files right back.

SonOfANoMomGoat · 2015-08-25 06:20:30

@severach Do you have a package that I could look at to see how you have the *.default scheme set up? I read through the 'HANDLING CONFIG FILES' and I see how the 3 way compare works, but it seems that those only work if you have the files in the backup array in PKGBUILD. I read another forum post from a while ago where a user was going to open a ticket to see if PKGBUILD's could be configured to accept directories in the backup array, but I don't think that was implemented, I tried to read through the actual git to see how makepkg works but I'm really noob when it comes to shell scripting.

It would be nice if I could just change the upstream source to better fit, but it's pretty much set how it's going to be.

Thanks to everyone for their pointers and helping. I've already found a number of mistakes I was making with my depends and other meta info after reading the wiki a few times.

progandy · 2015-08-25 07:48:08

SonOfANoMomGoat wrote:

The template directory contains about 20 files to start with plus whatever files the user adds after installation. I'm not sure the globbing loop with work, at least it would be an unsightly beast.

Is that really so unsightly?

pkgname=backupdir
pkgver=0.1
pkgrel=1
pkgdesc="test backup directory contents"
arch=(any)
url="http://example.com"
license=('GPL')
backup=()

build() {
  :
}

package() {
  ## find must be executed relative to $pkgdir
  cd "$pkgdir"
  ## define backup directory (relative to $pkgdir)
  local __dir="etc/backupdir"

  ## make some sample files
  mkdir -p "$__dir"
  touch "$__dir/a.conf"
  echo file_b >"$__dir/b.conf"
  mkdir -p "$__dir/sub"
  echo subtest >"$__dir/sub/sub.conf"

  ## add files to backup (relative paths due to cd and relative $__dir)
  local _backup && mapfile -t _backup < <(find "$__dir" -type f ) && backup+=("${_backup[@]}")
  ## if you don't have subdirectories, a simple glob works
  ## prepend a noop to hide it from mksrcinfo and prevent running it in the wrong context
  # : && backup+=( "$__dir"/*.conf )
}

Last edited by progandy (2015-08-25 11:13:36)

SonOfANoMomGoat · 2015-08-25 07:52:41

Thanks for the example, I was thinking for the loop I would have to manually list out each file to be added to backup. I've got a lot to learn it seems!

SonOfANoMomGoat · 2015-08-25 08:31:26

It looks like the following works out:

# Maintainer: Dan Schaper ( dschaper at ganymeade dot com)
# Contributor: ajs124 < aur AT ajs124 DOT de >

pkgname=rpimonitor-dev-git
_pkgbase=rpimonitor
pkgdesc="A self monitoring application designed to run on Raspberry Pi. Development branch."
arch=('armv6h' 'armv7h')
license=('GPL')
pkgver=2.10.r50.g7e031a5
pkgrel=1
depends=(rrdtool perl-http-daemon perl-json perl-ipc-sharelite perl-file-which)
makedepends=('git')
url=(https://github.com/XavierBerger/RPi-Monitor)
source=($pkgname::git://github.com/XavierBerger/RPi-Monitor.git#branch=devel)
sha512sums=('SKIP')
backup=(etc/${_pkgbase}/{data,daemon}.conf)
conflicts=('rpimonitor')

pkgver() {
  cd "$pkgname"
  git describe --long --tags | sed 's/^v//;s/\([^-]*-g\)/r\1/;s/-/./g'
}

prepare() {
  cd "$pkgname"/${_pkgbase}
  ln -sf ./template/arch.conf data.conf
  cat daemon.conf data.conf > rpimonitord.cf
  ../tools/conf2man.pl ./rpimonitord.cf ${pkgver} > rpimonitord.conf.5
  ../tools/help2man.pl ./rpimonitord ${pkgver} > rpimonitord.1
}

package() {
  cd ${pkgname}/${_pkgbase}
  install -Dm755 -t ${pkgdir}/usr/bin/ ${_pkgbase}d
  install -Dm644 -t ${pkgdir}/etc/$_pkgbase/ *.conf
  install -Dm644 -t ${pkgdir}/etc/$_pkgbase/template ./template/*
  install -Dm644 -t ${pkgdir}/usr/lib/systemd/system/ ../tools/systemd/*
  install -Dm644 -t ${pkgdir}/var/lib/rpimonitor/ updatestatus.txt
  install -Dm755 -t ${pkgdir}/usr/share/${_pkgbase}/scripts ../scripts/*.pl
  cp -a web ${pkgdir}/usr/share/${_pkgbase}/
  install -Dm644 -t ${pkgdir}/usr/share/man/man1 ${_pkgbase}d.1
  install -Dm644 -t ${pkgdir}/usr/share/man/man5 ${_pkgbase}d.conf.5
  cd ${pkgdir}
  local __dir="etc/$_pkgbase/template"
  : && backup+=( "$__dir"/*.conf)
}

.PKGINFO

# Generated by makepkg 4.2.1
# using fakeroot version 1.20.2
# Tue Aug 25 08:17:42 UTC 2015
pkgname = rpimonitor-dev-git
pkgver = 2.10.r50.g7e031a5-1
pkgdesc = A self monitoring application designed to run on Raspberry Pi. Development branch.
url = https://github.com/XavierBerger/RPi-Monitor
builddate = 1440490662
packager = Unknown Packager
size = 1603584
arch = armv7h
license = GPL
conflict = rpimonitor
backup = etc/rpimonitor/data.conf
backup = etc/rpimonitor/daemon.conf
backup = etc/rpimonitor/template/arch.conf
backup = etc/rpimonitor/template/axp209_cpu_pmu_temp.conf
backup = etc/rpimonitor/template/cpu_arch.conf
backup = etc/rpimonitor/template/cpu.conf
backup = etc/rpimonitor/template/dht11.conf
backup = etc/rpimonitor/template/example.badge_and_label.conf
backup = etc/rpimonitor/template/example.customrrd.conf
backup = etc/rpimonitor/template/example.justgage.conf
backup = etc/rpimonitor/template/example.progressbar.conf
backup = etc/rpimonitor/template/example.visibility.conf
backup = etc/rpimonitor/template/memory_arch.conf
backup = etc/rpimonitor/template/memory.conf
backup = etc/rpimonitor/template/network.conf
backup = etc/rpimonitor/template/printer.conf
backup = etc/rpimonitor/template/raspbian.conf
backup = etc/rpimonitor/template/raspbmc.conf
backup = etc/rpimonitor/template/sdcard.conf
backup = etc/rpimonitor/template/sdcard_raspbmc.conf
backup = etc/rpimonitor/template/sdcard_xbian.conf
backup = etc/rpimonitor/template/services.conf
backup = etc/rpimonitor/template/storage.conf
backup = etc/rpimonitor/template/sunxi_axp209.conf
backup = etc/rpimonitor/template/swap.conf
backup = etc/rpimonitor/template/temperature.conf
backup = etc/rpimonitor/template/temperature_xbian.conf
backup = etc/rpimonitor/template/uptime.conf
backup = etc/rpimonitor/template/version.conf
backup = etc/rpimonitor/template/wlan.conf
backup = etc/rpimonitor/template/xbian.conf
depend = rrdtool
depend = perl-http-daemon
depend = perl-json
depend = perl-ipc-sharelite
depend = perl-file-which
makedepend = git
makepkgopt = strip
makepkgopt = docs
makepkgopt = !libtool
makepkgopt = !staticlibs
makepkgopt = emptydirs
makepkgopt = zipman
makepkgopt = purge
makepkgopt = !upx
makepkgopt = !debug

Raynman · 2015-08-25 08:50:59

Am I missing something or is the ": &&" on the last line of the package function just a useless addition?

progandy · 2015-08-25 09:42:44

Raynman wrote:

Am I missing something or is the ": &&" on the last line of the package function just a useless addition?

It is not useless. It prevents makepkg/mksrcinfo from extracting the backup variable while generating the .SRCINFO file for a source package and running the glob at the wrong location. This way, it is only read when package() is executed and the binary package is created. This is necessary since the files cannot be found during the source package creation.

Raynman · 2015-08-25 10:26:15

progandy wrote:

Raynman wrote:
Am I missing something or is the ": &&" on the last line of the package function just a useless addition?
It is not useless. It prevents makepkg/mksrcinfo from extracting the backup variable while generating the .SRCINFO file for a source package and running the glob at the wrong location. This way, it is only read when package() is executed and the binary package is created. This is necessary since the files cannot be found during the source package creation.

Ah, yes, that makes sense. I'd say that deserves an explanatory comment at least as much as the filename generation, though.

severach · 2015-08-27 09:09:10

Not mentioning the user changeable files in backup will get them lost. Any file not in backup will be callously deleted by Pacman on the next upgrade or remove.

See AUR package lone-tar for an example of self managed possibly configurable files. I don't worry about unowned files in named folders. If package foo owns /usr/share/foo/bar then it's a safe bet that the package probably owns all the other files too.

That's a commercial product not intended for packaging so you'll find it hard to follow. The principle is very simple. In package you rename all the configurable files to foo.default. In post_install and post_upgrade you copy them all back, no clobber. The first time they won't exist.

post_install() {
  local _cfgfile
  for _cfgfile in /usr/share/foo/*.default; do
    cp -pn "${_cfgfile}" "${_cfgfile%.default}"
  done
}

In pre_upgrade you delete the unchanged ones.

post_install() {
  local _cfgfile
  for _cfgfile in /usr/share/foo/*.default; do
    if [ "$(md5sum < "${_cfgfile}")" = "$(md5sum < "${_cfgfile%.default}")" ]; then
      rm -f "${_cfgfile%.default}"
    fi
  done
}

In post_upgrade you might print a pithy message about the files that couldn't be upgraded. You can make these files survive removal if you want.

Arch Linux

#1 2015-08-10 02:55:49

[SOLVED] New PKGBUILD critiques needed.

#2 2015-08-10 04:56:53

Re: [SOLVED] New PKGBUILD critiques needed.

#3 2015-08-10 13:25:19

Re: [SOLVED] New PKGBUILD critiques needed.

#4 2015-08-10 16:41:29

Re: [SOLVED] New PKGBUILD critiques needed.

#5 2015-08-10 18:01:55

Re: [SOLVED] New PKGBUILD critiques needed.

#6 2015-08-10 18:12:48

Re: [SOLVED] New PKGBUILD critiques needed.

#7 2015-08-11 02:08:33

Re: [SOLVED] New PKGBUILD critiques needed.

#8 2015-08-11 04:01:55

Re: [SOLVED] New PKGBUILD critiques needed.

#9 2015-08-25 06:20:30

Re: [SOLVED] New PKGBUILD critiques needed.

#10 2015-08-25 07:48:08

Re: [SOLVED] New PKGBUILD critiques needed.

#11 2015-08-25 07:52:41

Re: [SOLVED] New PKGBUILD critiques needed.

#12 2015-08-25 08:31:26

Re: [SOLVED] New PKGBUILD critiques needed.

#13 2015-08-25 08:50:59

Re: [SOLVED] New PKGBUILD critiques needed.

#14 2015-08-25 09:42:44

Re: [SOLVED] New PKGBUILD critiques needed.

#15 2015-08-25 10:26:15

Re: [SOLVED] New PKGBUILD critiques needed.

#16 2015-08-27 09:09:10

Re: [SOLVED] New PKGBUILD critiques needed.

Board footer