fpv-wtf / opkg-repo Goto Github PK

It would be nice to have a scheduled update that checks if newer packages are available and if so, trigger a new build, keeping the old packages and publish as soon as a change is detected.

Since it would only need to check the repos latest release, we would probably be able to run it fairly often since we cache the big chunk of the work anyway.

The control files field can be extended easily allowing us to add pretty much arbitrary fields to the Package index.

Some of our packages already use the Homepage field, which I will be using to link to the README in the configurator.

Further this also solves the issue for fonts, we can use the native section filed to classify the packages, further we can add arbitrary other fileds, so we could for example expect each package that has the section field set to fonts to also have a screenshot field where we pass URLs to screenshots as JSON (the control file is not a yml) or a more general Meta field:

Package: font-test-package
Version: 0.0.1
Section: fonts
Architecture: armv7-3.2
Maintainer: Your Name <[email protected]>
MD5Sum: 02055df280bc2bac6d824e3234e90b0e
Size: 802
Filename: font-test-package_0.0.1_armv7-3.2.ipk
Description: This is just a test package for fonts
HomePage: https://link.to/example/readme
Screenshots: ["url_1", "url_2"]
Meta: {"key": "value", "key_1": ["item 1", "item 2"]}

I would prefer to utilize the Sections filed and the "generic" Meta field which contains all needed information for a specific section type. This would allow us to only need to parse two additional fields in the configurator in order to handle a variety of different package types.

I think all contributed packages should have a dependency to the wtfos-system package. This allows us to uninstall wtfos cleanly by only uninstalling wtfos-system, triggering the removal of all depending packages.

For most packages it will probably not matter since they will only "live" in the /blackbox/opt/* env, but in case something needs to write to some external files this would be a good option for a proper cleanup.

If you think this makes sense, I'd add it to the Readme and the example repo. Further I could also check this dependency when building the package index.

Otherwise msp-osd will just be listed twice. The description can be used to differentiate but I think it could still get a little bit confusing.

I think it would be nice to either have a naming convention that indicates on which devices the packages can be use - or separate repositories for the devices.

• all: works on airunit and goggle
• goggle: only works on goggle (for example LED related functionality)
• airunit: only works on airunit (for example msp OSD part for goggles)

Unstable branch with the latest unstable release.
Latest unstable release should only be added if it is newer than the latest stable release.

Unstable repo should then have a higher priority than the stable release and we should be able to handle versioning properly

URL: http://repo.fpv.wtf/pigeon-unstable or http://repo.fpv.wtf/unstable/pigeon/

While we still have relatively few packages I think it'd be a good idea to make a Discord channel (and an associated role to subscribe to pings?) where a bot would announce any package updates with the release notes grabbed from the appropriate repo/linked to.

One simple (and flexible) way of doing this is via Apprise: https://github.com/caronc/apprise

I've created the #updates channel and will DM @stylesuxx the appropriate token.