| Summary: | [meta-swupd] Try to consolidate OS_VERSION and DISTRO_VERSION | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] Other YP Layers | Reporter: | Joshua Lock <joshuagloe> |
| Component: | meta-swupd | Assignee: | Joshua Lock <joshuagloe> |
| Status: | RESOLVED NOTABUG | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | Low | CC: | igor.stoppa, poky.bs.watcher, poky.watcher |
| Version: | 2.2 | ||
| Target Milestone: | Future | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
|
Description
Joshua Lock
2016-03-01 09:36:55 UTC
Some thoughts, from a user perspective: * in general the generation of swupd data doesn't come for free (more space, more build time), so it might be preferable to have it set as a configurable option (beyond the inheritance or not from the swupd-image class) * in the context of the previous bullet point, the swupd version vs build id reminds me of sha id vs tag in a git tree: every commit has a hash but not every commit is tagged. So here we could consider them in the same way: related but not identical. * building on the previous 2 points, the id used by swupd could be provided without any pre-defined value, so that it is more obvious that this value really need to be provided from the outer context, be it CI pumping out progressive numbers, or a developer who has explicitly enabled the creation of swupd data and wants to generate a local repo that will be fed to a specific device (which in turn will be running a certain version and will update only to a higher number). I'm increasingly of the opinion that this isn't a big issue and I think Igor's comment backs this. Closing as NOTABUG unless someone actually requests this consolidation. |