| Summary: | Make koha-l10n get upgraded when koha-common gets upgraded | ||
|---|---|---|---|
| Product: | Koha | Reporter: | Aleisha Amohia <aleisha> |
| Component: | Packaging | Assignee: | Bugs List <koha-bugs> |
| Status: | NEW --- | QA Contact: | Testopia <testopia> |
| Severity: | enhancement | ||
| Priority: | P5 - low | CC: | dcook, mtj, tomascohen |
| Version: | Main | ||
| Hardware: | All | ||
| OS: | All | ||
| Change sponsored?: | --- | Patch complexity: | --- |
| Documentation contact: | Documentation submission: | ||
| Text to go in the release notes: | Version(s) released in: | ||
| Circulation function: | |||
|
Description
Aleisha Amohia
2024-11-14 22:51:47 UTC
I've been thinking about this topic on and off for a little while regarding Debian packages in general... Typically, one hard-codes required version numbers for dependencies into debian/control (or whatever process that builds it like debian/update-control in Koha). But we don't usually know the Koha/koha-l10n version until we give it to debian/build-git-snapshot (or an alternative Koha Debian package builder if you're me) which is a fairly last minute thing... We use dch -v to set the version number, which should flow through to one of the variables listed in "man deb-substvars" such as source:Version or binary:Version. That said... I don't know how well that will work for custom Debian packages which rely on the community koha-l10n package. So we might need to think of something a bit different. Possibly a custom variable in debian/control (and debian/control.in naturally), and then I think the version could be managed in debian/rules. Anyway, food for thought. Moving this to the Packaging component. |