flashprog: add new package

[connollydavid]

📦 Package Details

Maintainer: @connollydavid

Description:
Adds flashprog 1.5 in four variants, splitting the programmers by the libraries
they need.

---

🧪 Run Testing Details

• OpenWrt Version: main and 25.12
• OpenWrt Target/Subtarget: x86/64
• OpenWrt Device: Intel N150

Closes #29591

---

✅ Formalities

• I have reviewed the CONTRIBUTING.md file for detailed contributing guidelines.

If your PR contains a patch:

This PR contains no patches.

[BKPepe]

The split into four variants makes sense if it provides a meaningful reduction in package size and/or dependencies, but the PR currently doesn't show that. Could you provide the package/installed sizes of the four variants (ideally including their dependencies) and briefly explain the intended use case for each variant?

Also, since flashprog is already provided as the full variant and the other variants all have the same description, it would be useful to clarify when a user should choose flashprog-spi, flashprog-pci, or flashprog-external instead of the default full package.

[openwrt-ai]

Fresh review of the single commit c84a34c. The commit message matches what the diff does (four variants, the programmer split, and the deliberate per-variant binary names), and the packaging basics look right: PKG_MAINTAINER is set, the define indentation follows the metadata/recipe convention, BuildPackage is called with literal package names, and test.sh avoids grep -q.

Two inline comments, both about the variant layout rather than about correctness — neither blocks a merge as far as I can tell.

---

Generated by Claude Code

[connollydavid]

Hi Josef, thanks for taking a look. I was skeptical of needing variants
myself, but the dependencies changed my mind. The sizes below are from this
branch built for x86/64, in bytes. installed is apk's own
installed-size. The +deps columns add the dependency closure, counting
libatomic1 because libusb pulls it, and excluding libc, libpthread and librt.

package	programmers	.apk	installed	.apk +deps	installed +deps
flashprog-spi	4	99,575	684,818	99,575	684,818
flashprog-pci	21	174,863	873,731	203,837	935,964
flashprog-external	20	144,122	783,543	243,708	1,027,401
flashprog	37	217,439	968,351	345,999	1,274,442

Dependencies counted: flashprog-pci libpci; flashprog-external libftdi1,
libgpiod, libjaylink, libusb-1.0, libatomic1; flashprog those six together.
So flashprog-spi lands 589,624 bytes lighter than flashprog and pulls in
nothing.

Every variant carries dummy, linux_mtd, linux_spi and mstarddc_spi,
which reach a flash chip through the kernel. That is all flashprog-spi
carries, so it suits a device programming a chip it already talks to.

flashprog-pci adds the internal and PCI device programmers, which reach a
flash chip through the mainboard chipset or a card on the bus. It suits a
device programming its own board.

flashprog-external adds the programmers that attach over USB, a serial port
or GPIO lines. It suits a device used as the flashing host for a chip on
another board.

flashprog carries all of them.

I have given each variant its own description saying which programmers it
carries and which libraries it needs, so the package list answers this too,
and dropped DEFAULT_VARIANT since the four names are distinct and share no
PROVIDES.

p.s. sorry for not including initially. I was desperately trying not to
waffle :)

-dc

[efahl]

You ought to stick that table into the commit message, so non-github users can see it, too.

[connollydavid]

thanks @efahl, done, I edited commit message for terseness too (and put closes tag in the right place!).

[openwrt-ai]

Re-review of the force-pushed f176d9f (replaces c84a34c). The branch was also rebased onto current master, so the only change to this PR's own files is in utils/flashprog/Makefile.

DEFAULT_VARIANT:=1 is gone, which resolves my earlier comment — with four distinct package names and no shared PROVIDES, it had no effect. The four per-variant descriptions are the standard $(call Package/<pkg>/Default/description) idiom used by ~100 other Makefiles in the feed, and the library lists match each variant's DEPENDS exactly. The commit message now carries the size table, its programmer counts are self-consistent (4 base + 17 pci + 16 external = 37 full) and match the numbers you posted in the thread, and the subject scope matches the files touched. All 14 checks are green on this head.

Two nits inline, neither blocking.

One earlier thread is still open and unanswered: the per-variant binary renaming on lines 124/129/134 means the command a user types depends on which variant they installed, so upstream docs and any script calling flashprog only work with the full variant. Your comment explains what each variant is for, which is useful, but doesn't say whether installing two of them side by side is an actual use case — that's the part that would justify renaming over CONFLICTS/ALTERNATIVES. Worth a line either way so the thread can be closed.

---

Generated by Claude Code

[openwrt-ai]

Re-review of the force-pushed 0d71900 (replaces f176d9f). The only change is inside the four description blocks of utils/flashprog/Makefile — 6 insertions, 4 deletions, no other file touched. The commit message is byte-identical to the previous head and still matches what the diff does, so no commit checks this round.

Both nits from the last round are addressed:

• libusb → libusb-1.0 in the flashprog and flashprog-external descriptions (lines 71 and 79), so every library named across the four descriptions is now the exact feed package name.
• flashprog-pci and flashprog-spi each gained the missing "when to pick it" clause ("for a chip the kernel permits direct access to" / "for a chip it already exposes"), so all three narrow variants now read in parallel with flashprog-external.

The library lists still match each variant's DEPENDS exactly, and all four earlier threads are resolved, including the binary-renaming one. All 14 checks are green on this head.

Reviewed 1 new commit; no new issues found.

---

Generated by Claude Code

[efahl]

I'm sort of curious about your decision to name the delivered binaries all differently, rather than just flashprog for each of them.

Seems a lot like the dnsmasq or tc situation, where if you've got a "small" version installed and you need something from a bigger/different one, you just apk del x-small && apk add x-big to get the functionality. That keeps your commands consistent across installs (i.e., it's always flashprog --blah blah blah), so documentation and scripting is much simplified...

[connollydavid]

hi @efahl i was matching flashrom 's beat here (albeit, using flashprog's real group names).
i prefer your suggested way but given their overlap it seemed weird.

happy to revise to your way, maybe flashrom itself would benefit from an update to this pattern too (isn't APK great!)?

cheers
-dc

[efahl]

I'm not sure we'd want to change flashrom, as it looks like it has been that way for a while, but since these variants are new, it would probably be better to follow the dnsmasq path. You were already part way there with the DEFAULT_VARIANT, just need to add PROVIDES:=flashprog for each narrow variant and change each Package/x/install section to just write the binary as .../usr/bin/flashprog.

Here's how it's done in dnsmasq, note the default dnsmasq package doesn't have a PROVIDES:=dnsmasq, as that is implicit from the package name.

https://github.com/openwrt/openwrt/blob/main/package/network/services/dnsmasq/Makefile#L51

You ultimately end up with something that looks like this on your device, where the DEFAULT_VARIANT gives that package a package-priority in the .apk, and all the variants provides: <package>=version.

$ apk query --format yaml --fields package,provides,provider-priority 'dnsmasq*'
# 3 items
- package: dnsmasq-2.93-r1
  provider-priority: 100
  provides: # 1 items
    - dnsmasq-any
- package: dnsmasq-dhcpv6-2.93-r1
  provides: # 2 items
    - dnsmasq=2.93-r1
    - dnsmasq-dhcpv6-any
- package: dnsmasq-full-2.93-r1
  provides: # 2 items
    - dnsmasq=2.93-r1
    - dnsmasq-full-any

[connollydavid]

@efahl I went with the variant pattern, with one deviation from dnsmasq: all four variants provide flashprog-bin rather than flashprog. That keeps flashprog as the full package's own name instead of turning it into a virtual any variant can satisfy.

So apk add flashprog installs the full package, and fails if a smaller variant is already present. Swapping is unchanged: apk del flashprog-spi && apk add flashprog.

[openwrt-ai]

Re-review of the force-pushed 0c5278d (replaces 0d71900). The change is the switch to the variant/PROVIDES pattern: PROVIDES:=flashprog-bin in Package/flashprog/Default, DEFAULT_VARIANT:=1 back on the full package, the three per-variant install blocks collapsed into Package/<variant>/install = $(Package/flashprog/install), and the matching case collapse in test.sh.

The commit message was updated in step with it — "each installs the same binary under its own name, so any combination can be installed together" became "each installs the same binary, and the variants are mutually exclusive" — so the message still matches the diff and the size table is unaffected by the rename. No commit checks this round.

I checked the mechanism against the build system rather than just against neighbours:

• flashprog-bin carries no @ prefix and the package has no ABI version, so AddProvide emits it as flashprog-bin=1.5, i.e. a versioned provide — "only one version of a provide can be installed at the same time". That is what actually makes the four variants exclusive under apk, and it is the same device the wget-ssl/wget-nossl example in that file describes.
• Putting the shared provide on all four (rather than dnsmasq's "narrow variants provide the base name") also lines up with add_implicit_provides_conflicts: it needs one provider marked variant_default, which DEFAULT_VARIANT:=1 now supplies, and it generates the Conflicts entries and the menuconfig exclusions from there. Without the re-added DEFAULT_VARIANT that pass would bail out, so the two halves of this commit belong together.
• Package/<x>/install = $(Package/flashprog/install) is the established feed idiom (~30 Makefiles, e.g. libs/libulfius/Makefile, net/haproxy/Makefile), and the recursive assignment still satisfies the ifdef Package/$(1)/install gate in package-pack.mk, so the three variants keep their install step.
• test.sh still avoids grep -q, and flashprog --version prints flashprog v1.5, which contains PKG_VERSION, so no test-version.sh is needed.

All 14 checks are green on this head, and the earlier binary-naming thread is now settled by the change itself.

Reviewed 1 new commit; no new issues found.

---

Generated by Claude Code

[efahl]

Just one nit: It seems like listing the dependencies in the descriptions is redundant, as 1) you could get them with apk query ... and 2) if they change, then you need to edit the file in two places so (non-functionally) error prone.

Otherwise, looks good to me!

[connollydavid]

hi, fixed, thanks so much for all your time on this!