Control file fields extension

[stylesuxx]

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.

[j005u]

"Section" is an odd choice from opkg instead of something like "Category" or "Type", but it is what it is.

ConfiguratorMeta? The whole file is already metadata, it's a bit confusing otherwise maybe?

Do we just embed the JSON? Could that get out of hand? Do we want to support URIs (both links and uriencoded data) instead/in addition?

[stylesuxx]

"ConfiguratorMeta" is fine with me - you are right - less confusing. We can also introduce category or type, I just thought since "category" is there, why not use it. I still need to check what it actually does in opkg context i would imagine you could use that as a filter directly (which since we use the index file itself does not matter too much for us).

We could use URI encoded data too. I would prefer to go with either or. Also I need to check, I am pretty sure opkg is using a fixed sized buffer for fields in control files. This does not matter much to us, but might make be problematic with opkg info in the CLI.

[j005u]

Opkg (entware) uses Section, we should probably stick with it. It's just a bit odd.

While having loose JSON in the control file slightly triggers me some way, I don't know that it's necessarily a bad solution. Just a thought that occurred.

I suppose the downsides of data URIs would be they are harder to edit directly. And actual https:// URI-s are a bit of an attack vector as they can be updated at any moment.

Tagging @bri3d for opinions, should he have any.

[druckgott]

Are there any news about Font instalation direct to the googles instead of sd. Then it´s posible to format the sd card anymore without loosing the fonts. I would realy appreciate this.