(→Other files: potential error messages) |
(more caution) |
||
| Line 18: | Line 18: | ||
You can add <code>preinst</code>, <code>postinst</code>, <code>extrainst_</code>, <code>prerm</code>, and <code>postrm</code> files to run scripts at various points of the package installation and uninstallation lifecycle. It's important to be conservative with this code - as [[Best Practices]] explains, "Do not use postinst/preinst/extrainst_ for file management purposes! Do not store in the package files or directories that your software could create. Do not enforce permissions that your package should contain. dpkg uses an expressive packaging format that has support for permissions, ownership, and links. Use that support!" | You can add <code>preinst</code>, <code>postinst</code>, <code>extrainst_</code>, <code>prerm</code>, and <code>postrm</code> files to run scripts at various points of the package installation and uninstallation lifecycle. It's important to be conservative with this code - as [[Best Practices]] explains, "Do not use postinst/preinst/extrainst_ for file management purposes! Do not store in the package files or directories that your software could create. Do not enforce permissions that your package should contain. dpkg uses an expressive packaging format that has support for permissions, ownership, and links. Use that support!" | ||
If your package scripts have problems, especially upon uninstallation, this can be very frustrating for your user because that can be very hard to fix for them. You don't want to cause the dreaded [http://theiphonewiki.com/wiki/Cydia_Errors#subprocess_pre-removal_script_returned_error_exit_status_.5Bnumber.5D "subprocess pre-removal script returned error" and "Sub-process /usr/bin/dpkg returned an error code"] error messages. | If your package scripts have problems, especially upon uninstallation, this can be very frustrating for your user because that can be very hard to fix for them. You don't want to cause the dreaded [http://theiphonewiki.com/wiki/Cydia_Errors#subprocess_pre-removal_script_returned_error_exit_status_.5Bnumber.5D "subprocess pre-removal script returned error" and "Sub-process /usr/bin/dpkg returned an error code"] error messages. A related unfortunate reality is that if your package has complex scripts, that can increase the chances that if a pirate repository poorly repackages your tweak, somebody doing "try before they buy" can run into those error messages and get frustrated. | ||
Documentation about these scripts in the Debian packaging manual: [https://www.debian.org/doc/manuals/debian-faq/ch-pkg_basics.en.html#s-maintscripts basics] and [https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html more info]. | Documentation about these scripts in the Debian packaging manual: [https://www.debian.org/doc/manuals/debian-faq/ch-pkg_basics.en.html#s-maintscripts basics] and [https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html more info]. | ||
Revision as of 21:35, 12 December 2014
Packaging is the step prior to sharing or releasing a tweak/application/tool/library/theme. Here you put all your project files into a single nicely wrapped file that others can install on their devices.
Cydia is based on Debian APT (Advanced Packaging Tool), so a lot of general documentation about packaging for APT also applies to packaging for Cydia.
Tools
To do: add existing tools, on which platforms they are available, how to use them.
DEBIAN folder
Control file
To do: add layout of fields, what do they mean, how they are used. Refer to saurik's post and links at the bottom.
If you need to list dependencies or conflicting packages, Debian's packaging manual may be useful (because Cydia packaging is based on Debian packaging): Syntax of relationship fields, Dependencies, Conflicts -- or if you're submitting this package to a default repository, you can just ask your repository maintainer for help with this.
Other files
You can add preinst, postinst, extrainst_, prerm, and postrm files to run scripts at various points of the package installation and uninstallation lifecycle. It's important to be conservative with this code - as Best Practices explains, "Do not use postinst/preinst/extrainst_ for file management purposes! Do not store in the package files or directories that your software could create. Do not enforce permissions that your package should contain. dpkg uses an expressive packaging format that has support for permissions, ownership, and links. Use that support!"
If your package scripts have problems, especially upon uninstallation, this can be very frustrating for your user because that can be very hard to fix for them. You don't want to cause the dreaded "subprocess pre-removal script returned error" and "Sub-process /usr/bin/dpkg returned an error code" error messages. A related unfortunate reality is that if your package has complex scripts, that can increase the chances that if a pirate repository poorly repackages your tweak, somebody doing "try before they buy" can run into those error messages and get frustrated.
Documentation about these scripts in the Debian packaging manual: basics and more info.
To do: Consider this paste as one example. Explain how it fits into Debian packaging (how it interacts with apt/aptitude/dpkg/Cydia).