Re: [OE-core] [PATCH 1/1] classes/kernel*: allow disabling symlink creation

Martin Jansa
2020-12-01T16:22:55Z

[-- Attachment #1: Type: text/plain, Size: 1957 bytes --]

Hi Paul,

I see, I was just worried that this case will block me pushing the last bit
of [YOCTO #12937] which changes symlinks to hardlinks:
https://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/artifacts

Which makes the use case you're fixing worse (as even less systems will
correctly handle hardlinks), so I support the idea to disable having the
links. My current work around is to just remove the unnecessary files when
rsyncing to file-server.

But the main issue which I'm seeing with my current implementation (and
with webos_deploy this is based on) is that we need the version-less
artifacts to be available, because e.g. image recipe searching kernel
artifact when there is DATETIME or SRCPV in the kernel artifact-name won't
be able to find it, because the image might be built at different DATETIME
and doesn't know anything about kernel SRCREV/SRCPV. To resolve this, the
build is using the version-less artifacts (always the latest one).

I guess your implementation might fail in such DATETIME cases as well.

With separate variable to disable the links we can somehow work around this
or at least warn user that without the version-less filenames, the
VERSION_SUFFIX variable needs to be stable (as no PV/SRCPV/DATATIME in it).

Cheers,

On Tue, Dec 1, 2020 at 5:13 PM Paul Eggleton <
bluelightning@bluelightning.org> wrote:

> Hi Martin
>
> (replying all this time)
>
> On Tuesday, 1 December 2020 15:40:36 NZDT you wrote:
> > Can we use a separate variable controlling this behavior other than
> > *_LINK_NAME variables being set to empty?
> >
> > Then we could easily extend it to stop creating the links also for image
> > artifacts as well.
>
> Well, I didn't call it out explicitly but I was just mirroring the image
> artifacts behaviour - we set those to "" as well and there are checks
> there
> already to make that disable the symlink in that case.
>
> Paul
>
>
>

[-- Attachment #2: Type: text/html, Size: 2567 bytes --]