<div dir="auto"><div>new recipe version (most likely) will have new release and expect any change</div><div dir="auto"><br></div><div dir="auto">If you are concerned about recipe version in your layer then manage that rather than copying original recipe file *as it is* in your layer</div><div dir="auto"><br></div><div dir="auto">When upgrading recipe, anyway have to test it to make sure your image doesn't break. So no way you will miss any breaking change introduced. And at that point you could have (if needed) your custom version in "file/" rather than always copying the working sample which is already maintained by someone else</div><div dir="auto"><br></div><div dir="auto">I wouldn't recommend to have copy of unchanged upstream files in a custom layer</div><div dir="auto"><br></div><div dir="auto">Cheers</div><div dir="auto">Ankur<br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Sat, Mar 21, 2020, 12:32 AM Robert P. J. Day <<a href="mailto:rpjday@crashcourse.ca">rpjday@crashcourse.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sat, 21 Mar 2020, Ankur Tyagi wrote:<br>
<br>
> what if sample file is updated in new version? Now you have to<br>
> maintain the copy in your "file/" as well.<br>
><br>
> If you are using sample file as it is, then keeping a copy is<br>
> probably not a good idea<br>
><br>
> Cheers<br>
> Ankur<br>
<br>
i actually think that's an argument in my favour ... i would be very<br>
nervous about how upgrading a recipe version would quietly upgrade my<br>
configuration file. i would far prefer to have to manually upgrade my<br>
configuration to keep in step.<br>
<br>
rday<br>
<br>
> got into a discussion yesterday about the "cleanest" way to design a<br>
> .bbappend file to install a package's configuration file, so i'm<br>
> curious about best practices, and here's an example. (and i'm asking<br>
> as it looks like this will be an issue for a number of recipes i'm<br>
> looking at.)<br>
><br>
> current recipe for conntrack-tools:<br>
><br>
> <a href="http://cgit.openembedded.org/meta-openembedded/tree/meta-networking/recipes-filter/conntrack-tools/conntrack-tools_1.4.5.bb" rel="noreferrer noreferrer" target="_blank">http://cgit.openembedded.org/meta-openembedded/tree/meta-networking/recipes-filter/conntrack-tools/conntrack-tools_1.4.5.bb</a><br>
><br>
> note how the recipe install step installs a conntrack.conf.sample<br>
> file:<br>
><br>
> do_install_append() {<br>
> install -d ${D}/${sysconfdir}/conntrackd<br>
> install -d ${D}/${sysconfdir}/init.d<br>
> install -m 0644 ${S}/doc/sync/ftfw/conntrackd.conf ${D}/${sysconfdir}/conntrackd/conntrackd.conf.sample<br>
> ...<br>
><br>
> so far, so good. now, in cases where a sample conf file is provided,<br>
> there is, of course, no guarantee that it will be applicable out of<br>
> the box -- one *expects* that it might be necessary to tweak such a<br>
> file and install it as part of a .bbappend file. and here's the point<br>
> of contention.<br>
><br>
> in this current situation, it turns out that that sample conf file<br>
> just happens to be appropriate, so the entire .bbappend file for this<br>
> recipe consists of:<br>
><br>
> do_install_append () {<br>
> install -m 0644 \<br>
> ${D}/${sysconfdir}/conntrackd/conntrackd.conf.sample \<br>
> ${D}/${sysconfdir}/conntrackd/conntrackd.conf<br>
> }<br>
><br>
> yes, that will work, but i suggested that, even though it's<br>
> convenient, the problem with that approach is that looking at the<br>
> .bbappend file doesn't show you the contents of the file that will be<br>
> installed. to see the actual conf file, you'd have to peruse the<br>
> source, or check the final result ... you get the idea.<br>
><br>
> i suggested that, even though the sample file in *this* case was<br>
> perfectly appropriate, i would choose to make a copy of it under<br>
> files/, and install the conf file from *there*, the advantage being<br>
> that the actual file being installed is immediately readable.<br>
><br>
> does anyone have any strong opinions on this? it seems mundane, but<br>
> i think the latter approach is still superior, especially since i<br>
> suspect most sample configuration files would have to be adjusted,<br>
> anyway.<br>
><br>
> thoughts? just trying to collect some best practices to apply to<br>
> this project.<br>
><br>
> rday<br>
> --<br>
> _______________________________________________<br>
> Openembedded-core mailing list<br>
> <a href="mailto:Openembedded-core@lists.openembedded.org" target="_blank" rel="noreferrer">Openembedded-core@lists.openembedded.org</a><br>
> <a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer noreferrer" target="_blank">http://lists.openembedded.org/mailman/listinfo/openembedded-core</a><br>
><br>
><br>
><br>
<br>
-- <br>
<br>
========================================================================<br>
Robert P. J. Day Ottawa, Ontario, CANADA<br>
<a href="http://crashcourse.ca" rel="noreferrer noreferrer" target="_blank">http://crashcourse.ca</a><br>
<br>
Twitter: <a href="http://twitter.com/rpjday" rel="noreferrer noreferrer" target="_blank">http://twitter.com/rpjday</a><br>
LinkedIn: <a href="http://ca.linkedin.com/in/rpjday" rel="noreferrer noreferrer" target="_blank">http://ca.linkedin.com/in/rpjday</a><br>
========================================================================</blockquote></div></div></div>