All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul Eggleton" <bluelightning@bluelightning.org>
To: Martin Jansa <martin.jansa@gmail.com>
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] [PATCH 1/1] classes/kernel*: allow disabling symlink creation
Date: Wed, 02 Dec 2020 06:13:58 +1300	[thread overview]
Message-ID: <4074215.1IzOArtZ34@linc> (raw)
In-Reply-To: <CA+chaQc4dmqWxU5o1AbPpN9Pj37ZAGpgy0bMisgpzyj_m66C+Q@mail.gmail.com>

On Wednesday, 2 December 2020 05:22:43 NZDT Martin Jansa wrote:
> 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/artifact
> s
> 
> 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).

That is a good point and we have the same problem here - what I'm planning to
do is to set a bunch of the other variables such that there are no versioned
artifacts - i.e. the real files effectively appear in place of the symlinks and
the versioned ones disappear. It seems to work in my tests so far. With my
patchset this is what I set:

------------ snip ------------
IMAGE_LINK_NAME = ""
IMAGE_VERSION_SUFFIX = ""
IMAGE_NAME_SUFFIX = ""
IMAGE_MANIFEST_distroname = "${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.manifest"

KERNEL_ARTIFACT_NAME = "${MACHINE}"
KERNEL_ARTIFACT_LINK_NAME = ""
------------ snip ------------

I have found that I still need the plain type named kernel artifacts (e.g. vmlinux),
and since these don't actually use the link name variable I have changed those to
be written out even if the link name is blank (v2 patchset still in testing). We could
introduce another variable to disable those but I hadn't planned to do that
for the moment.

Cheers,
Paul




      reply	other threads:[~2020-12-01 17:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-26  1:01 [PATCH 0/1] classes/kernel*: allow disabling symlink creation Paul Eggleton
2020-11-26  1:01 ` [PATCH 1/1] " Paul Eggleton
2020-11-27  3:55   ` [OE-core] " Paul Eggleton
2020-12-01  2:40     ` Martin Jansa
2020-12-01 16:13       ` Paul Eggleton
2020-12-01 16:22         ` Martin Jansa
2020-12-01 17:13           ` Paul Eggleton [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4074215.1IzOArtZ34@linc \
    --to=bluelightning@bluelightning.org \
    --cc=martin.jansa@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.