[PATCH v2 6/7] coreutils: Import from packages feed

Brian Norris computersforpeace at gmail.com
Mon Jan 9 12:23:25 PST 2023

On Mon, Jan 9, 2023 at 11:56 AM Christian Marangi <ansuelsmth at gmail.com> wrote:
> On Mon, Jan 09, 2023 at 11:51:53AM -0800, Brian Norris wrote:
> > For my use, it feels like a simplified form (which only needs to be a
> > stdin/stdout pipeline) would be pretty easy to inline into the
> > caldata/firmware-loader script:
> >
> >   ucode -e 'import { stdin } from "fs"; print(b64dec(stdin.read("all")));'
> >
> Ok a single line solution will be ideal and easy to include in the
> hotplug script.

Sounds good.

> > > 2. Ucode is part of the core packages? Or an optional dependency for
> > > luci and fw4? In theory it should be always present or as a safe thing
> > > we should add ucode in the required packages for this target?
> >
> > So far I don't find it as a strict core dependency, but just happens
> > to be available by default due to dependencies. I guess similar
> > questions to the busybox, coreutils, etc., stuff -- whether we're OK
> > with forcing 'ucode' as a per-target dependency / DEVICE_PACKAGES.
> >
> If it's not a strict core dependency I would just put ucode as a
> dependency for the needed devices and be done with it. It's not a low
> space target and ucode is not that big and for sure smaller than lua,
> openssl and easier to implement than moving coreutils from feeds to
> core.

Sounds good to me.

Thanks all for the help.

> Think with v3 and this implemented the series is ready.

Great! Unfortunately, I'm still dependent on an outstanding patch for
the fstools project:
See also patch 7's notes.

I guess I could revert to the 2-partition layout (which does not
depend on the fstools change) for the time being, so snapshots would
work. I'm still trying to figure out what the best partitioning and
syupgrade strategy is best for disk space flexibility and for
reliability (e.g., not clobbering rootfs_data when it's appended to
rootfs) on block devices...


More information about the openwrt-devel mailing list