Conary takes a radically different approach to install-time scripts than legacy package management tools do. Typical install-time scripts are package-oriented instead of file-oriented, primarily composed of boilerplate, and often clash with rollback (for those package management tools that even try to provide rollback functionality). Conary tags individual files, instead; this file is a shared library, that file is an init script, another file is an X font. Then, at install time, once for each transaction (which may be many troves all together), it calls tag handler scripts to do whatever is required with the tagged files.
Bugs in tag handlers demonstrate some of the good characteristics of this system. When a bug in a tag handler is fixed, that bug is fixed for all packages in one place, without any need to copy code or data around. It is fixed even for older versions of packages built before the tag handler was fixed (as long as the package in question is not the one that implements the tag handler). Also, tag handlers can be called based not only on changes to the tagged files, but also changes to the tag handler itself, including bug fixes. Finally, the tag handlers are files in the filesystem, not packaging metadata, so a system administrator can manipulate them and even use them independent of package management.
While tag handlers are clearly an improvement over legacy install-time scripts, it is still possible to make many of the same mistakes.
It is always slower to run a script than to package the results of running a script. Therefore, if you can perform the action at packaging time instead, do so. For example, put files in the /etc/cron.d/ directory instead of calling the crontab program or editing the /etc/crontab file.
The more programs a script calls, the more complex the dependency set needed to run it. Circular dependencies are worse; they will break, one way or another. Finally, calling more programs increases the risk of accidental circular dependencies.
Modifying file data or metadata that is under package management and storing backup copies of files are generally inappropriate for any package manager, not just Conary. With Conary, though, a few more things are inappropriate, including calling programs like useradd or groupadd to add users and groups to the system—it is too late; the files have already been created. (Although user and group management is actually accomplished using a tag handler, or internal code in Conary if the tag handler has not yet been installed, there is special handling inside of Conary for the info- packages that implement user and group handling.)
Scripts that do not check for error return codes can easily wreak havoc by assuming that previous actions succeeded. (We have discovered that if you are having difficulty managing error handling in a tag handler, you may be taking an approach that is needlessly complex. Look for a simpler way to solve the problem.)
It is also easy to misapply assumptions developed while writing legacy install-time scripts to tag handler scripts. The most important thing to remember is that everything in Conary, including tag handlers, is driven by changes. Therefore, if a package includes five files with the foo tag, and none of those tagged files is affected by an update, the foo tag handler will simply not be called during that update operation. If only two of the five files is modified in the update, the foo tag handler will be called during that update operation, but it will be told only about the the two modified files, not all five tagged files.
Write tag handlers with rollbacks in mind. This means that if the user does the inverse operation in Conary, the effect of the tag handler should be inverted as well. Most post-installation tasks merely involve updating caches, and often the list of affected files is not even required in order to update the cache. These cases are easy; just run the program which regenerates the cache.
When inventing new tag names, keep the tag mechanism in mind. mypackage-script is a horrible name for a tag handler, because it initiates or perpetuates the wrong idea about what it is and how it works. The name of a tag handler should describe the files so tagged. The sentence ``file is a(n) tag name'' should sound sensible, as in ``/lib/libc-2.3.2.so is a shlib'' or ``/usr/share/info/gawk.info.gz is an info-file''. Following this rule carefully has helped produce clean, simple, fast, relatively bug-free tag handlers.