On Mon, Nov 26, 2012 at 8:57 AM, Martin Jansa <span dir="ltr"><<a href="mailto:martin.jansa@gmail.com" target="_blank">martin.jansa@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Mon, Nov 26, 2012 at 08:49:32AM -0500, Bruce Ashfield wrote:<br>
> On Mon, Nov 26, 2012 at 7:37 AM, Martin Jansa <<a href="mailto:martin.jansa@gmail.com">martin.jansa@gmail.com</a>>wrote:<br>
><br>
> > * so it will work look KERNEL_IMAGE<br>
> > * also we were recreating modules.tgz with every kernel build, but<br>
> > overwritting the same output file<br>
> ><br>
> > Signed-off-by: Martin Jansa <<a href="mailto:Martin.Jansa@gmail.com">Martin.Jansa@gmail.com</a>><br>
> > ---<br>
> > meta/classes/kernel.bbclass | 7 ++++++-<br>
> > 1 file changed, 6 insertions(+), 1 deletion(-)<br>
> ><br>
> > diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass<br>
> > index ee59aaf..9c70e70 100644<br>
> > --- a/meta/classes/kernel.bbclass<br>
> > +++ b/meta/classes/kernel.bbclass<br>
> > @@ -497,6 +497,10 @@ KERNEL_IMAGE_BASE_NAME ?=<br>
> > "${KERNEL_IMAGETYPE}-${PE}-${PV}-${PR}-${MACHINE}-${DA<br>
> > # Don't include the DATETIME variable in the sstate package signatures<br>
> > KERNEL_IMAGE_BASE_NAME[vardepsexclude] = "DATETIME"<br>
> > KERNEL_IMAGE_SYMLINK_NAME ?= "${KERNEL_IMAGETYPE}-${MACHINE}"<br>
> > +MODULE_TARBALL_BASE_NAME ?=<br>
> > "modules-${PE}-${PV}-${PR}-${MACHINE}-${DATETIME}.tgz"<br>
> > +# Don't include the DATETIME variable in the sstate package signatures<br>
> > +MODULE_TARBALL_BASE_NAME[vardepsexclude] = "DATETIME"<br>
> > +MODULE_TARBALL_SYMLINK_NAME ?= "modules-${MACHINE}.tgz"<br>
> ><br>
> > do_uboot_mkimage() {<br>
> > if test "x${KERNEL_IMAGETYPE}" = "xuImage" ; then<br>
> > @@ -526,7 +530,8 @@ addtask uboot_mkimage before do_install after<br>
> > do_compile<br>
> > kernel_do_deploy() {<br>
> > install -m 0644 ${KERNEL_OUTPUT}<br>
> > ${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin<br>
> > if (grep -q -i -e '^CONFIG_MODULES=y$' .config); then<br>
> > - tar -cvzf<br>
> > ${DEPLOYDIR}/modules-${KERNEL_VERSION}-${PR}-${MACHINE}.tgz -C ${D} lib<br>
> > + tar -cvzf ${DEPLOYDIR}/${MODULE_TARBALL_BASE_NAME} -C ${D}<br>
> > lib<br>
> > + ln -sf ${MODULE_TARBALL_BASE_NAME}.bin<br>
> > ${MODULE_TARBALL_SYMLINK_NAME}<br>
> ><br>
><br>
> Just a quick question, are there any concerns about existing users of the<br>
> old tgz name ? Obviously, if they were in oe-core, we'd know about them<br>
> and update them, but I have no idea myself how much (if anything) was based<br>
> on the old name. I'm not sure of the best practices oe-core/oe uses for<br>
> cases<br>
> like this in the past, so I thought I'd ask.<br>
<br>
</div></div>I remember seeing some thread about making whole modules tarball<br>
creation optional and disabled by default, so I guess there is only a<br>
few users of this.<br></blockquote><div><br></div><div>Agreed. It isn't common, the modules package yes .. the tarball, not that I've</div><div>heard much about.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> The old shorter name was nice, but I agree that having it different than<br>
> the image<br>
> name makes it non obvious how to associate the image and modules, and that's<br>
> a nice thing to fix.<br>
<br>
</div>True, but since oldname was the same for different kernel images I<br>
always found misleading to see 5 different uImages and only one modules<br>
tarball (which we know was created during build of latest uImage - but<br>
maybe not newest uImage version wise - so quite confusing for someone<br>
just trying to download matching uImage and modules).<br></blockquote><div><br></div><div>I definitely agree.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> Since we are already making a symlink, I guess we could consider<br>
> a transnational<br>
> symlink with the old name ? (but then again, if the link is there, people<br>
> will continue<br>
> to have dependencies on it and not update their own code).<br>
<br>
</div>I don't mind having 2 symlinks if there is the need for old name.<br></blockquote><div><br></div><div>I'd wait to see if anyone pops up with a strong opinion. I'm all for making the</div><div>file names consistent, but having a temporary symlink to catch any outliers<br>
might be a good thing too.</div><div><br></div><div>So I'm a solid "maybe" :) I'm hoping RP has a stronger opinion on the migration</div><div>path from the existing name.</div><div><br></div><div>Cheers,</div>
<div><br></div><div>Bruce</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Martin 'JaMa' Jansa jabber: <a href="mailto:Martin.Jansa@gmail.com">Martin.Jansa@gmail.com</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"<br>
</div>