Le mercredi 18 décembre 2024 à 11:09:35 UTC+1, MOESSBAUER, Felix a écrit :

On Tue, 2024-12-17 at 12:50 -0800, Cedric Hombourger wrote: 
> 
> 
> Le jeudi 5 décembre 2024 à 15:55:35 UTC+1, Uladzimir Bely a écrit : 
> > On Thu, 2024-12-05 at 06:47 -0800, Stephen Ecker wrote: 
> > > I keep getting this error: 
> > > 
> > > | ERROR: A native program mksquashfs required to build the image 
> > > was 
> > > not found (see details above). 
> > > | 
> > > | Please make sure wic-tools have squashfs-tools-native in its 
> > > DEPENDS, build it with 'bitbake wic-tools' and try again. 
> > > | 
> > > 
> > > I have tried adding squashfs-tools-native to WKS_FILE_DEPENDS, 
> > > but I 
> > > get the same error.  any thoughts? 
> > 
> > Hello. 
> > 
> > Try using IMAGER_INSTALL:wic += "squashfs-tools" 
> 
> 
> I have recently run into this (and did this in my layer) 
> 
> IMO the wic imager should pre-install packages for everything file- 
> systems it supports / usable in .wks files. I was going to submit a 
> patch along these lines so that I could get rid of this directive in 
> my downstream layer. Should I? This would improve usability / user- 
> experience if you ask me.  

Hmm... I tend to disagree. Installing these tools takes time and 
increases the attack surface of the build itself. By that we basically 
penalize all users just because it makes things a bit easier for some. 


attack surface? isn't the sbuild environment of the imager ephemeral?
moreover, users are encouraged to build within a (kas-)container, this adds 
another line of defense

as for build-times, we can quantify but I believe it is negligible.
little gains but increased pains (for some at least)?  

I believe we are reaching out to developers with varying levels of 
knowledge and that's ok because some just want to focus on their 
application development duties and do not care about the platform-level 
stuff, yet they have to use the platform tools (bitbake / isar) to get 
their job done. From that perspective, I would vote for lowering the 
barrier of entry
 
of course one approach could be to add some pre-processing task where we 
parse the wks file upfront to check file-systems that were selected 
(possibly with some shortcuts to avoid re-implementing a full wks parser in 
isar/meta/imagetypes*) but that sounds like adding unnecessary complexity.

anyhow, that's my view of the matter.


Best regards, 
Felix 

> 
> Thanks 
> Cedric 
> 
> > 
> > > -- 
> > > You received this message because you are subscribed to the 
> > > Google 
> > > Groups "isar-users" group. 
> > > To unsubscribe from this group and stop receiving emails from it, 
> > > send an email to isar-users+...@googlegroups.com. 
> > > To view this discussion visit 
> > > 
https://groups.google.com/d/msgid/isar-users/2839131c-156b-4007-b424-854d267cb0abn%40googlegroups.com 
> > 
> > > . 
> > 
> > -- 
> > Best regards, 
> > Uladzimir. 
> > 
> > 
> > 

-- 
Siemens AG, Technology 
Linux Expert Center 


-- 
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/isar-users/ad0e20d5-f37f-4fa8-8842-a26e0503a345n%40googlegroups.com.