Consolidating excepts from discussions elsewhere:

@l-arnold #1831 (comment)

Not a TKLDEV used system, but quite Branch and Generation related, I did build "turnkeylinux-odoo-tools"(https://github.com/l-arnold/turnkeylinux-odoo-tools) recently as a method to move a TKL Odoo 16.1 install up to 17.1 as TKLBAM itself was not working for me given differences in the base Odoo Code. TKLDEV could have been enlisted for this, though technically the full process was refactoring the unsupported Odoo Debian package out of the updated system, and simultaneously moving the file locations to more accessibly and commonly used /opt/odoo path. I will work on a 17.1 to 18 method for the same soon. Here, I will likely try to have a Odoo 14 side by side with Odoo 16 (build by TKL 18 default), then have methods to have them coexist and potentially migrate between them. Having an Odoo 15 in between would allow the OCA Open Upgrade process to work.

@marcos-mendez #1831 (comment)

odoo-tools as a first-class packaging component

Your turnkeylinux-odoo-tools addresses a real and recurring pain point. I think the right path forward is to integrate it directly into the Odoo appliance packaging layer — similar to how tkl-php-upgrade was adopted into every PHP-dependent upstream appliance. Odoo version transitions are inevitable (they happen every ~18 months), and having a standardized, appliance-native upgrade path rather than ad-hoc migration scripts would benefit the entire TKL Odoo user base.
Extending odoo-tools: OCA verticals

Taking this further, I would love to collaborate on extending odoo-tools to support automated installation of OCA (Odoo Community Association) verticals. The OCA ecosystem provides essential modules for localization, accounting, logistics, HR, and many other domains — and having a clean method to layer them on top of a TKL Odoo appliance would be a significant value-add.

That said, this becomes considerably more complex on Trixie/v19. Python 3.13 on Debian Trixie enforces PEP 668 strictly, which means virtual environments are no longer optional — they are mandatory. The --break-system-packages flag exists but is not a reliable long-term strategy. Several OCA dependencies are notorious for conflicting with system packages, particularly around the reporting engine (wkhtmltopdf/weasyprint chains) and the geoengine stack (GDAL/GEOS/Shapely). Getting a clean, reproducible OCA vertical install on Trixie will require careful venv isolation and dependency pinning.