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

[Christian Marangi]

On Mon, Jan 09, 2023 at 12:23:25PM -0800, Brian Norris wrote:
> 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:
> https://patchwork.ozlabs.org/project/openwrt/patch/20230107020424.1703752-1-computersforpeace@gmail.com/
> 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...
> 

We have way to make old image not compatible with partition change and
stuff so migrating to a new implementation in the future won't be that
problematic.

But it would be good if we can sort it out before... Need to check that
fstool patch better and see if something can be done.

-- 
	Ansuel