Hi, CE team would like to request new tracks called “18” and “20” to publish the uefi-fw-tools snap that will be based on core18 and core20. I recalled a previous discussion about the same bases representing core18 or core20 as tracks but from my perspectives originally the uefi-fw-tools snap was always used for core system only, and for classic system there is a fwupd snap provided by upstream maintainer, so I think they’re explicit to users for usage.
For newer version of uefi-fw-tools snap, it keeps confined based on fwupd upsteram (currently the version we integrated: 1.4.2) and specifically uefi-fw-tools carries some patches for core system, so that’s why we have distinct snaps.
However, usage of this pattern is restricted to snaps that have a legitimate and unsurmountable need to depend on the base system, which is typically not the case (as snaps can declare a base and snapd ensures that base and its resources are available to the snap).
Can you give a bit more detail on why uefi-fw-tools requires release-specific builds in a way that can’t be covered by specifying a base?
Thanks for reviewing this, and I’ve read that request from Alfonso. Indeed, there are some points to be clear from my misunderstanding:
A new uefi-fw-tools snap declares “core18” as base, but it uses the upstream branch as source to build snap. This is not what Bluez/NM/MM did using Ubuntu release as source tracking.
It means that even we create a “core20” base for uefi-fw-tools then in the build we still use upstream version but the changes are possible.
So, using the upstream version as track is absolutely fine and reasonable to me.
Currently, the uefi-fw-tools follows the fwupd release version which is 1.4.2, so it should make sense to create a “1.4” track for that. Although, the upstream still releases 1.3.X, for developing consideration, I’d prefer tracking the latest branch first.
If you only want to offer 1.4 version and not 1.3 for now, you probably don’t need tracks. In any case, I would suggest:
Put 1.4 in the latest track (this track always exists).
If you want to make 1.3 available, we can create a 1.3 track; it’s better to use tracks for old releases and not for new/current ones.
Once 1.4 becomes legacy (say, when 1.5 appears) we can create a 1.4 track and people who need the old version explicitly can then use 1.4 as a track and 1.5 would use latest.
That said, the main criteria for tracks is whether users are likely to have a reason to choose an older release. Do you think users of uefi-fw-tools would need an old version explicitly, or can they just use the latest one at all times?
Probably we can not pin 1.4 in the latest track as most machines which are preinstalled the current uefi-fw-tools (fwupd version was 0.7.2 which is also super outmoded) depends on the core 16. Some of them came from our commercial projects delivered, so it’s highly risk to do this from my point of view. That says, if any customer requires that the uefi-fw-tools needs to be shipped with core16, we have to satisfy them. I would still ask for creating 1.4 as a track for the upstream version. Also, the classic fwupd[1] snap is using 1.4.4 as stable.
ok, +1 from me, using tracks for a newer release is a slightly unusual pattern but if some preinstalls depend on the old version then it sounds reasonable to keep that in “latest” (unfortunately named, but that ship has sailed) and publish new ones in release-specific tracks.
TO be clear, I would be creating the 1.4 track, is that OK?
I’ll need to wait a bit for other reviewers to look at this request.
Yes, please create a new track 1.4, we will have a plan later on to transit the old one after making sure everything work flawlessly on 1.4 with all preinstall .
