Create two Debian packages:
The first contains device tree overlays and configures loading at boot.
The second packages the designspark.esdk module.
Strategy
Looking at resources such as:
https://wiki.debian.org/PackagingWithGit
Appears as though the best approach might be to create two new branches in this repo, one for each package. E.g. debian-esdk-hardware and debian-python3-esdk (struggled to think of shorter names that sufficiently convey purpose).
Releases
We should start tagging releases in addition to storing the version in setup.py. So we would do this after merging to main. Following which with Debian packaging we would then:
- Merge main to each packaging branch, so that they have the latest tagged release.
- Make necessary updates to packaging, e.g. version metadata and any new dependencies.
- Tag Debian package versions?
Not sure about this last step and more reading required.
Note that package maintainers are frequently not the developers and they may apply fixes to upstream code, or patches so that it works properly on a particular distro. Hence packages tend to have a longer version string, which clearly identifies the local/downstream version.
Dev
Would suggest forking this repo and experimenting with the fork.
Create two Debian packages:
The first contains device tree overlays and configures loading at boot.
The second packages the designspark.esdk module.
Strategy
Looking at resources such as:
https://wiki.debian.org/PackagingWithGit
Appears as though the best approach might be to create two new branches in this repo, one for each package. E.g. debian-esdk-hardware and debian-python3-esdk (struggled to think of shorter names that sufficiently convey purpose).
Releases
We should start tagging releases in addition to storing the version in setup.py. So we would do this after merging to main. Following which with Debian packaging we would then:
Not sure about this last step and more reading required.
Note that package maintainers are frequently not the developers and they may apply fixes to upstream code, or patches so that it works properly on a particular distro. Hence packages tend to have a longer version string, which clearly identifies the local/downstream version.
Dev
Would suggest forking this repo and experimenting with the fork.