Date   

Re: Kernel Header UAPI Issue

Karthik Poduval
 

Hi Khem and Bruce,

I got the patch from raspberry pi github and it looked like it put the header into include/uapi/linux/dma-heap.h, for kernel 5.4 it doesn't look like there is a need for a Kbuild file. Are any special steps needed for exporting the header (I thought kernel 5.4 exports everything from include/uapi directory) ? The  linux-libc-headers sound like the issue. Thanks for the pointers, I will dig up further based on the suggestions and revert.

On Mon, Feb 22, 2021 at 5:14 PM Bruce Ashfield <bruce.ashfield@...> wrote:
On Mon, Feb 22, 2021 at 7:52 PM Karthik Poduval
<karthik.poduval@...> wrote:
>
> I have a 5.4 kernel where I applied a patch (using a .scc file) from
> kernel 5.6 which brings in dmabuf heaps.
>
> The patch exports a uapi header
> include/uapi/linux/dma-heap.h.
> I am trying to write an application that uses dmabuf with a recipe (no
> special DEPENDS).
>
> It is able to find
> #include<linux/dma-buf.h>
> but not
> #include<linux/dma-heap.h> (this file is introduced in the patch)
>
> I looked at the recipe's sysroot
> recipe-sysroot/usr/linux/include


That's coming from the linux-libc-headers, your new upi header is not
part of the libc-headers package, so it won't show up there. And no,
it shouldn't be part of that recipe and the libc-headers should not be
generated from the current state of whatever kernel is being built.

You need to arrange for it to be exported and staged separately (look
for examples of 'sysroot_stage' variants in the meta-data, you can
bbappend the behaviour to your kernel recipe), or your code can look
for the header in the kernel shared workdir (STAGING_KERNEL_BUILDDIR)
by adding that to your include paths in the recipe.

As khem also mentioned, you'll need to make sure that the uapi header
is not just patched in, but properly exported.

Bruce

>
> and  dma-buf.h is there but not  dma-heap.h
>
> Why is the header not being imported ?
>
> --
> Regards,
> Karthik Poduval
>
>
>


--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


--
Regards,
Karthik Poduval


Re: Kernel Header UAPI Issue

Bruce Ashfield
 

On Mon, Feb 22, 2021 at 7:52 PM Karthik Poduval
<karthik.poduval@gmail.com> wrote:

I have a 5.4 kernel where I applied a patch (using a .scc file) from
kernel 5.6 which brings in dmabuf heaps.

The patch exports a uapi header
include/uapi/linux/dma-heap.h.
I am trying to write an application that uses dmabuf with a recipe (no
special DEPENDS).

It is able to find
#include<linux/dma-buf.h>
but not
#include<linux/dma-heap.h> (this file is introduced in the patch)

I looked at the recipe's sysroot
recipe-sysroot/usr/linux/include

That's coming from the linux-libc-headers, your new upi header is not
part of the libc-headers package, so it won't show up there. And no,
it shouldn't be part of that recipe and the libc-headers should not be
generated from the current state of whatever kernel is being built.

You need to arrange for it to be exported and staged separately (look
for examples of 'sysroot_stage' variants in the meta-data, you can
bbappend the behaviour to your kernel recipe), or your code can look
for the header in the kernel shared workdir (STAGING_KERNEL_BUILDDIR)
by adding that to your include paths in the recipe.

As khem also mentioned, you'll need to make sure that the uapi header
is not just patched in, but properly exported.

Bruce


and dma-buf.h is there but not dma-heap.h

Why is the header not being imported ?

--
Regards,
Karthik Poduval



--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


Re: Kernel Header UAPI Issue

Khem Raj
 

On Mon, Feb 22, 2021 at 4:52 PM Karthik Poduval
<karthik.poduval@gmail.com> wrote:

I have a 5.4 kernel where I applied a patch (using a .scc file) from
kernel 5.6 which brings in dmabuf heaps.

The patch exports a uapi header
include/uapi/linux/dma-heap.h.
I am trying to write an application that uses dmabuf with a recipe (no
special DEPENDS).

It is able to find
#include<linux/dma-buf.h>
but not
#include<linux/dma-heap.h> (this file is introduced in the patch)

I looked at the recipe's sysroot
recipe-sysroot/usr/linux/include
and dma-buf.h is there but not dma-heap.h

Why is the header not being imported ?
What does patch look like? just adding the file is not enough, it
should be added to makefiles to be exported as UAPI header

--
Regards,
Karthik Poduval



Kernel Header UAPI Issue

Karthik Poduval
 

I have a 5.4 kernel where I applied a patch (using a .scc file) from
kernel 5.6 which brings in dmabuf heaps.

The patch exports a uapi header
include/uapi/linux/dma-heap.h.
I am trying to write an application that uses dmabuf with a recipe (no
special DEPENDS).

It is able to find
#include<linux/dma-buf.h>
but not
#include<linux/dma-heap.h> (this file is introduced in the patch)

I looked at the recipe's sysroot
recipe-sysroot/usr/linux/include
and dma-buf.h is there but not dma-heap.h

Why is the header not being imported ?

--
Regards,
Karthik Poduval


[PATCH yocto-autobuilder-helper] send-qa-email: Save the QA email in case it doesn't reach the mailing lists.

Michael Halstead
 

Signed-off-by: Michael Halstead <mhalstead@linuxfoundation.org>
---
scripts/send-qa-email | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/scripts/send-qa-email b/scripts/send-qa-email
index 6785df3..1b69307 100755
--- a/scripts/send-qa-email
+++ b/scripts/send-qa-email
@@ -145,6 +145,10 @@ Build hash information: \n

''' % (args.release, args.publish_dir.replace(web_root, web_url), buildhashes)

+# Store a copy of the email in case it doesn't reach the lists
+with open(os.path.join(args.publish_dir, "qa-email"), "wb") as qa_email:
+ qa_email.write(email.encode('utf-8'))
+
utils.printheader("Sending QA email")
env = os.environ.copy()
# Many distros have sendmail in */sbin
--
2.29.2


QA notification for completed autobuilder build (yocto-3.1.6.rc1)

Pokybuild User <pokybuild@...>
 

A build flagged for QA (yocto-3.1.6.rc1) was completed on the autobuilder and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.1.6.rc1


Build hash information:

bitbake: fa94374baea75a94e3a488126ca7d8e241a77acd
meta-arm: 02c660521619ddb7a9495d65403aaa2636747ce8
meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
meta-intel: 4bd62a7e154b8c9e8a114f452d3b062d8d058118
meta-kernel: f793168bd19af3d8c5a260dd35f387ed9a31794b
meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
oecore: a8debddd6cbdd70db74e096d72f97fbee008ee63
poky: a13bda44fcda4e79e9aed39ca1495eabecb6a7b7



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@linuxfoundation.org


Enhancements/Bugs closed WW08!

Stephen Jolley
 

All,

The below were the owners of enhancements or bugs closed during the last week!

Who

Count

richard.purdie@...

5

chee.yang.lee@...

1

dorindabassey@...

1

anuj.mittal@...

1

Grand Total

8

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Current high bug count owners for Yocto Project 3.3

Stephen Jolley
 

All,

Below is the list as of top 50 bug owners as of the end of WW08 of who have open medium or higher bugs and enhancements against YP 3.3.   There are 47 possible work days left until the final release candidates for YP 3.3 needs to be released.

Who

Count

richard.purdie@...

30

ross@...

25

david.reyna@...

20

bluelightning@...

15

bruce.ashfield@...

12

JPEWhacker@...

10

trevor.gamblin@...

9

yifan.yu@...

8

kai.kang@...

7

akuster808@...

7

mark.morton@...

7

chee.yang.lee@...

5

raj.khem@...

5

Qi.Chen@...

5

sakib.sajal@...

5

idadelm@...

4

yi.zhao@...

4

randy.macleod@...

4

mingli.yu@...

3

timothy.t.orling@...

3

alejandro@...

3

hongxu.jia@...

3

saul.wold@...

3

stacygaikovaia@...

3

mostthingsweb@...

3

jon.mason@...

2

jeanmarie.lemetayer@...

2

ydirson@...

2

limon.anibal@...

2

matthewzmd@...

2

nicolas.dechesne@...

2

jaewon@...

2

anuj.mittal@...

2

pokylinux@...

2

sangeeta.jain@...

2

liezhi.yang@...

2

yoctoproject@...

1

shachar@...

1

dorindabassey@...

1

mshah@...

1

mister_rs@...

1

steve@...

1

charles.davies@...

1

kergoth@...

1

mhalstead@...

1

matt.ranostay@...

1

twoerner@...

1

aehs29@...

1

mark.hatle@...

1

Martin.Jansa@...

1

changqing.li@...

1

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Yocto Project Newcomer & Unassigned Bugs - Help Needed

Stephen Jolley
 

All,

 

The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs  Also please review: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and how to create a bugzilla account at: https://bugzilla.yoctoproject.org/createaccount.cgi

The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project.  If anyone can help, please take ownership of the bug and send patches!  If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 354 unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out with these.  Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system.  There are also roughly four different "priority" classes right now, “3.2”, “3.3, "3.99" and "Future", the more pressing/urgent issues being in "3.2" and then “3.3”.

 

Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm@...) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account).  The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Re: [opkg-devel] [opkg-utils PATCH v2] Makefile: separate manpages and utils install

Alex Stewart
 

Hey Ryan,

This looks good to me. I'll merge this patch tomorrow, if there are no objections.

Thanks,

--
Alex Stewart
Software Engineer - NI Real-Time OS
NI (National Instruments)

alex.stewart@ni.com


Updating Yocto

Claude Bing
 

Hello all. My organization has been working with Yocto recently, and we
have noticed that there are often weird errors encountered after
updating revisions within a release branch (e.g., 3.1.3 -> 3.1.5). Is
there an accepted process to merging in upstream changes? Here is a
distillation of our workflow:

* Yocto releases 3.1.0 / dunfell

* Create a local tracking branch for the Yocto release
"sample-yocto-dunfell" based on upstream 3.1.0 tag / dunfell branch.
This is necessary because some of our local tooling is located in the
top level directory and it is a pain to copy the files each time.

* Create firmware with Yocto

* Yocto releases 3.1.x

* Merge upstream yocto-3.1.x tag into local tracking branch

* Create firmware with Yocto

Sometimes, after this last step, we encounter problems where patches
cannot be applied, or files cannot be found when bitbake tries to build
the recipes. We have tried deleting build/{tmp,sstate-cache} whenever we
merge upstream changes, but random errors still persist. For each of
these packages, if we run "bitbake -c cleanall", the error goes away.

Most of the time, these recipes have not been extended in our project,
so they are purely meta-oe / meta packages.

Are we doing something wrong, or is there a more acceptable way to
handle updates?

How tightly should meta-openembedded be tied to the core Yocto release?

--
Regards,

Claude Bing


[meta-security][PATCH 5/5] nikito: Update common-licenses references to match new names

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
recipes-scanners/buck-security/buck-security_0.7.bb | 2 +-
recipes-scanners/checksecurity/checksecurity_2.0.15.bb | 2 +-
recipes-security/nikto/nikto_2.1.6.bb | 2 +-
recipes-security/redhat-security/redhat-security_1.0.bb | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/recipes-scanners/buck-security/buck-security_0.7.bb b/recipes-scanners/buck-security/buck-security_0.7.bb
index 179eeda..20a1fb0 100644
--- a/recipes-scanners/buck-security/buck-security_0.7.bb
+++ b/recipes-scanners/buck-security/buck-security_0.7.bb
@@ -3,7 +3,7 @@ DESCRIPTION = "Buck-Security is a security scanner for Debian and Ubuntu Linux.
system. This enables you to quickly overview the security status of your Linux system."
SECTION = "security"
LICENSE = "GPL-2.0"
-LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6"
+LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/GPL-2.0-only;md5=801f80980d171dd6425610833a22dbe6"

SRC_URI = "http://sourceforge.net/projects/buck-security/files/buck-security/buck-security_${PV}/${BPN}_${PV}.tar.gz"

diff --git a/recipes-scanners/checksecurity/checksecurity_2.0.15.bb b/recipes-scanners/checksecurity/checksecurity_2.0.15.bb
index 204123d..0161b4c 100644
--- a/recipes-scanners/checksecurity/checksecurity_2.0.15.bb
+++ b/recipes-scanners/checksecurity/checksecurity_2.0.15.bb
@@ -2,7 +2,7 @@ SUMMARY = "basic system security checks"
DESCRIPTION = "checksecurity is a simple package which will scan your system for several simple security holes."
SECTION = "security"
LICENSE = "GPL-2.0"
-LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6"
+LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/GPL-2.0-only;md5=801f80980d171dd6425610833a22dbe6"

SRC_URI = "http://ftp.de.debian.org/debian/pool/main/c/checksecurity/checksecurity_${PV}.tar.gz \
file://setuid-log-folder.patch \
diff --git a/recipes-security/nikto/nikto_2.1.6.bb b/recipes-security/nikto/nikto_2.1.6.bb
index 2d2c46c..615cc30 100644
--- a/recipes-security/nikto/nikto_2.1.6.bb
+++ b/recipes-security/nikto/nikto_2.1.6.bb
@@ -4,7 +4,7 @@ SECTION = "security"
HOMEPAGE = "https://cirt.net/Nikto2"

LICENSE = "GPLv2"
-LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6"
+LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/GPL-2.0-only;md5=801f80980d171dd6425610833a22dbe6"

SRCREV = "f1bbd1a8756c076c8fd4f4dd0bc34a8ef215ae79"
SRC_URI = "git://github.com/sullo/nikto.git \
diff --git a/recipes-security/redhat-security/redhat-security_1.0.bb b/recipes-security/redhat-security/redhat-security_1.0.bb
index 56f734c..0d70dc6 100644
--- a/recipes-security/redhat-security/redhat-security_1.0.bb
+++ b/recipes-security/redhat-security/redhat-security_1.0.bb
@@ -2,7 +2,7 @@ SUMMARY = "redhat security tools"
DESCRIPTION = "Tools used by redhat linux distribution for security checks"
SECTION = "security"
LICENSE = "GPLv2"
-LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6"
+LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/GPL-2.0-only;md5=801f80980d171dd6425610833a22dbe6"

SRC_URI = "file://find-chroot-py.sh \
file://find-chroot.sh \
--
2.17.1


[meta-security][PATCH 4/5] scap-security-guide: Inherit python3targetconfig

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
.../scap-security-guide/scap-security-guide.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-security-compliance/recipes-openscap/scap-security-guide/scap-security-guide.inc b/meta-security-compliance/recipes-openscap/scap-security-guide/scap-security-guide.inc
index 32fce0f..d1a9511 100644
--- a/meta-security-compliance/recipes-openscap/scap-security-guide/scap-security-guide.inc
+++ b/meta-security-compliance/recipes-openscap/scap-security-guide/scap-security-guide.inc
@@ -10,7 +10,7 @@ DEPENDS = "openscap-native python3 python3-pyyaml-native python3-jinja2-native l

S = "${WORKDIR}/git"

-inherit cmake pkgconfig python3native
+inherit cmake pkgconfig python3native python3targetconfig

STAGING_OSCAP_BUILDDIR = "${TMPDIR}/work-shared/openscap/oscap-build-artifacts"
export OSCAP_CPE_PATH="${STAGING_OSCAP_BUILDDIR}${datadir_native}/openscap/cpe"
--
2.17.1


[meta-security][PATCH 3/5] openscap: Inherit python3targetconfig

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
meta-security-compliance/recipes-openscap/openscap/openscap.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-security-compliance/recipes-openscap/openscap/openscap.inc b/meta-security-compliance/recipes-openscap/openscap/openscap.inc
index afa576a..812ea9f 100644
--- a/meta-security-compliance/recipes-openscap/openscap/openscap.inc
+++ b/meta-security-compliance/recipes-openscap/openscap/openscap.inc
@@ -11,7 +11,7 @@ DEPENDS_class-native = "pkgconfig-native swig-native curl-native libxml2-native

S = "${WORKDIR}/git"

-inherit cmake pkgconfig python3native perlnative
+inherit cmake pkgconfig python3native python3targetconfig perlnative

PACKAGECONFIG ?= "python3 rpm perl gcrypt ${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 'selinux', '', d)}"
PACKAGECONFIG[python3] = "-DENABLE_PYTHON3=ON, ,python3, python3"
--
2.17.1


[meta-security][PATCH 2/5] python3-suricata-update: Inherit python3targetconfig

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
recipes-ids/suricata/python3-suricata-update_1.1.1.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-ids/suricata/python3-suricata-update_1.1.1.bb b/recipes-ids/suricata/python3-suricata-update_1.1.1.bb
index 0070b5b..732ca9a 100644
--- a/recipes-ids/suricata/python3-suricata-update_1.1.1.bb
+++ b/recipes-ids/suricata/python3-suricata-update_1.1.1.bb
@@ -10,6 +10,6 @@ SRC_URI = "git://github.com/OISF/suricata-update;branch='master-1.1.x'"

S = "${WORKDIR}/git"

-inherit python3native setuptools3
+inherit python3native python3targetconfig setuptools3

RDEPENDS_${PN} = "python3-pyyaml"
--
2.17.1


[meta-security][PATCH 1/5] apparmor: Inherit python3targetconfig

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
recipes-mac/AppArmor/apparmor_3.0.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-mac/AppArmor/apparmor_3.0.bb b/recipes-mac/AppArmor/apparmor_3.0.bb
index 35e95a0..015205d 100644
--- a/recipes-mac/AppArmor/apparmor_3.0.bb
+++ b/recipes-mac/AppArmor/apparmor_3.0.bb
@@ -39,7 +39,7 @@ PARALLEL_MAKE = ""

COMPATIBLE_MACHINE_mips64 = "(!.*mips64).*"

-inherit pkgconfig autotools-brokensep update-rc.d python3native perlnative cpan systemd features_check bash-completion
+inherit pkgconfig autotools-brokensep update-rc.d python3native python3targetconfig perlnative cpan systemd features_check bash-completion

REQUIRED_DISTRO_FEATURES = "apparmor"

--
2.17.1


Re: Include "my.conf" in conf/local.conf

Peter Bergin
 

Hi,

On 2021-02-22 14:29, Mauro Ziliani wrote:

Hi all

Is it possible to include a fine in local.conf?


yes. Just add "include my.conf" in your configuration.

https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-metadata.html#include-directive

Regards,
/Peter

MZ





Iignore variable change in the complete recipe #python #yocto

rkthebest@...
 

Hello,

we are using a recipe to fetch binary from artifactory and package it in rootfile system.
and this artifactory path can be dynamic so i am using linux system variable to pass this information to the recipe by
d.getVar("SYSTEM_VAR",True)
and then using this variable in recipe to fetch binary from artifactory.

the problem is that when i change the "SYSTEM_VAR on linux machine then YOCTO complains "The metadata is not deterministic and this needs to be fixed"
because i am changing the variable without changing recipe, and the basehash value has changed.

what is the best way to solve the above problem?


Re: Custom python location on target #python

felixn1996@...
 

On Mon, Feb 22, 2021 at 05:44 AM, Josef Holzmayr wrote:
I personally would probably go with a build-in-build, and put some
form of application rootfs on the emmc - this could either be a simple
chroot or some more advanced form of container. This avoids nasty
breakages and update problems when the filesystems go out of version
sync. Other techniques might also apply depending on your software
rollout process, like an addtional overlay fs, or a pivot-root with
initrd, or.... it depends. But ripping out random packages and
rearranging them at random locations certainly isn't a good idea. It
already hurts when I think of the mount-and-deploy magic one would
need for this to roll out in production.

My $.02
Okay, that makes sense!
I'll look for a better solution. 

KR,
Felix 


Re: Private: Re: [yocto] Custom python location on target #python

Josef Holzmayr
 

(re-adding list as this certainly does not contain sensitive
information - others might add other opinions and hints, as well as my
answer should be available for everyone to find it.)

Am Mo., 22. Feb. 2021 um 14:35 Uhr schrieb <felixn1996@gmail.com>:

On Mon, Feb 22, 2021 at 04:57 AM, Josef Holzmayr wrote:

Whats the reasoning behind this? If its meant to be a work-around for
"my custom software totally wants it in that location", then you're
probably better off fixing your custom software to stick to canonical
paths. If its about partitioning schemes, other techniques might
apply. If its about being able to upgrade/modify python independently
from the system, then you probably want some root-in-root or container
build. But randomly picing a complex package that has system-wide
implications and saying "I want it here, screw the FHS" is not a good
idea usually.

Hi
I am aware that what I am asking for is a bit ugly.

The reason is that I have a small amount of memory at my disposal. I'm working with a setup with two partitions, a root-fs and an overlayed application file system. None of them has enough space for python.
Therefore I want to install it on the eMMC, which has plenty of space.
So instead of /usr which is on the root/app file system, I would install it under /media/<somewhere> on the mounted eMMC.

But maybe there exists a more elegant solution?
I personally would probably go with a build-in-build, and put some
form of application rootfs on the emmc - this could either be a simple
chroot or some more advanced form of container. This avoids nasty
breakages and update problems when the filesystems go out of version
sync. Other techniques might also apply depending on your software
rollout process, like an addtional overlay fs, or a pivot-root with
initrd, or.... it depends. But ripping out random packages and
rearranging them at random locations certainly isn't a good idea. It
already hurts when I think of the mount-and-deploy magic one would
need for this to roll out in production.

My $.02

Greetz

1041 - 1060 of 53453