opkg suport acls

[Piotr Łobacz]

Hi team, I'm recently dealing with turning on support for acls as libarchive already has it  and I have also discovered that there is already commented code in https://git.yoctoproject.org/opkg/tree/libopkg/opkg_archive.c#n909

Adding these extra attributes adds support when I do install on the device where opkg is installed. The problem occurs when I'm building an image with yocto kirkstone and there is this command https://git.openembedded.org/openembedded-core/tree/meta/lib/oe/package_manager/ipk/__init__.py#n368 which does the installation of all packages with -o parameter to use a dir as root file system. In such case these extra attributes are not being preserved.

My guess is that in this situation data.tar.* (in case of yocto kirkstone it would be data.tar.xz) is being first extracted to some extra place and than copied without preserving them, but I was not able to find it.

I would be very grateful if someone could give me some hint :)

P.S. I was also looking also by this offline_root parameter but could find anything interesting...

BR

Piotr

[Piotr Łobacz]

OK I have verified that going to devshell for my yocto image recipe and extracting this particular ipk package, which has these ACLs preserved with ar -x package.ipk and than calling tar --acls --xattrs -xpp data.tar.xz -C rootfs works.

I have also verified the opkg install -o / package.ipk command on the dedicated device and it does work either.

I double checked the opkg-native code and it has my patch applied so I really do not know what happens there. Any ideas?

[Alex Stewart]

I'm noticing quite a few places in the un-archive code where useful
warnings are emitted. Could you enable debug output and check the logs
for errors related to setting the disk options when creating the output
archive object [1]?

[1] https://git.yoctoproject.org/opkg/tree/libopkg/opkg_archive.c#n373

On 4/4/23 09:59, Piotr Łobacz wrote:
> OK I have verified that going to devshell for my yocto image recipe
> and extracting this particular ipk package, which has these ACLs

> preserved with *ar -x package.ipk* and than calling *tar --acls
> --xattrs -xpp data.tar.xz -C rootfs* works.
>
> I have also verified the *opkg install -o / package.ipk* command on

> the dedicated device and it does work either.
>
> I double checked the opkg-native code and it has my patch applied so I
> really do not know what happens there. Any ideas?
> wtorek, 4 kwietnia 2023 o 02:10:50 UTC+2 Piotr Łobacz napisał(a):
>
> Hi team, I'm recently dealing with turning on support for acls as
> libarchive already has it  and I have also discovered that there
> is already commented code in
> https://git.yoctoproject.org/opkg/tree/libopkg/opkg_archive.c#n909

> <https://urldefense.com/v3/__https://git.yoctoproject.org/opkg/tree/libopkg/opkg_archive.c*n909__;Iw!!FbZ0ZwI3Qg!vkxMexF2VxZOP-KnG8Bo-4GUU9z4v9bsMeEuzM_CByCLL-0AmCQl7izjQ8FdICfHCvWoHKpZKhesu_oic2Q$>

>
> Adding these extra attributes adds support when I do install on
> the device where opkg is installed. The problem occurs when I'm
> building an image with yocto kirkstone and there is this command
> https://git.openembedded.org/openembedded-core/tree/meta/lib/oe/package_manager/ipk/__init__.py#n368

> <https://urldefense.com/v3/__https://git.openembedded.org/openembedded-core/tree/meta/lib/oe/package_manager/ipk/__init__.py*n368__;Iw!!FbZ0ZwI3Qg!vkxMexF2VxZOP-KnG8Bo-4GUU9z4v9bsMeEuzM_CByCLL-0AmCQl7izjQ8FdICfHCvWoHKpZKhesclOKgL8$>

> which does the installation of all packages with -o parameter to
> use a dir as root file system. In such case these extra attributes
> are not being preserved.
>
> My guess is that in this situation data.tar.* (in case of yocto
> kirkstone it would be data.tar.xz) is being first extracted to
> some extra place and than copied without preserving them, but I
> was not able to find it.
>
> I would be very grateful if someone could give me some hint :)
>
> P.S. I was also looking also by this offline_root parameter but
> could find anything interesting...
>
> BR
> Piotr
>

> --
> You received this message because you are subscribed to the Google
> Groups "opkg-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to opkg-devel+...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/opkg-devel/71fe2abe-01db-459e-b755-c8c934f579abn%40googlegroups.com
> <https://urldefense.com/v3/__https://groups.google.com/d/msgid/opkg-devel/71fe2abe-01db-459e-b755-c8c934f579abn*40googlegroups.com?utm_medium=email&utm_source=footer__;JQ!!FbZ0ZwI3Qg!vkxMexF2VxZOP-KnG8Bo-4GUU9z4v9bsMeEuzM_CByCLL-0AmCQl7izjQ8FdICfHCvWoHKpZKhes_8JzGYw$>.

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

alex.s...@ni.com

[Alex Stewart]

That is odd.

Are you running your OE build within a container environment? I wonder
if the OE rootfs/ workspace is on a mount point which doesn't support
xattrs or has some other confounding settings, versus the unarchive
destination you're using to do your manual testing.

On 4/4/23 17:16, Piotr Łobacz wrote:
> BTW. I do not know what has happened but for some reason when I'm
> posting message to the subject they are being deleted...

I'm not sure what you mean.

>
> śr., 5 kwi 2023 o 00:10 Piotr Łobacz <pio.l...@gmail.com> napisał(a):
>
> Hi Alex thanks for your quick response,
> I have run it with -V4 for debuging I have also applied
> verification of extract_flags being set and the output looks like
> this:
>
> root@681efe99d9ed:/work/build/tmp-glibc/work/eg600-WelotecGmbH-linux/welotec-base-image/1.0-r0/welotec-base-image-1.0#
> opkg install --nodeps -o
> /work/build/tmp-glibc/work/eg600-WelotecGmbH-linux/welotec-base-image/1.0-r0/rootfs
> -V4 aziotctl_1.4.3.0+cfa39b58ec-r0_core2-64.ipk
> opkg_conf_parse_file: Loading conf file
> /work/build/tmp-glibc/work/eg600-WelotecGmbH-linux/welotec-base-image/1.0-r0/rootfs//etc/opkg/arch.conf.
> opkg_conf_parse_file: Supported arch all priority (1)
> opkg_conf_parse_file: Supported arch any priority (6)
> opkg_conf_parse_file: Supported arch noarch priority (11)
> opkg_conf_parse_file: Supported arch x86_64 priority (16)
> opkg_conf_parse_file: Supported arch core2-64 priority (21)
> opkg_conf_parse_file: Supported arch eg600 priority (26)
> opkg_conf_parse_file: Loading conf file
> /work/build/tmp-glibc/work/eg600-WelotecGmbH-linux/welotec-base-image/1.0-r0/rootfs//etc/opkg/opkg.conf.
> pkg_hash_load_feeds:
> pkg_hash_load_status_files:
> opkg_install_cmd: aziotctl_1.4.3.0+cfa39b58ec-r0_core2-64.ipk
> opkg_prepare_file_for_install: Package aziotctl provided by file
> 'aziotctl_1.4.3.0+cfa39b58ec-r0_core2-64.ipk'.
> pkg_vec_insert_merge: Adding new pkg=aziotctl
> version=1.4.3.0+cfa39b58ec arch=core2-64.
> pkg_info_preinstall_check: Updating file owner list.
> libsolv_solver_set_arch_policy: libsolv arch policy:
> eg600>core2-64>x86_64>noarch>any>all
> Package marked for install: aziotctl - 1.4.3.0+cfa39b58ec-r0
> Installing aziotctl (1.4.3.0+cfa39b58ec) on root
> opkg_install_pkg: Calling pkg_arch_supported.
> pkg_arch_supported: Arch core2-64 (priority 21) supported for pkg
> aziotctl.
> print_paths: Extracting '/tmp/opkg-L1JopR/aziotctl-u0byle/control'.
> print_paths: Extracting '/tmp/opkg-L1JopR/aziotctl-u0byle/preinst'.
> ar->extract_flags: 255
> update_file_ownership: update_file_ownership: new_pkg=aziotctl
> wants file
> /work/build/tmp-glibc/work/eg600-WelotecGmbH-linux/welotec-base-image/1.0-r0/rootfs/etc/,
> from owner=<NULL>
> update_file_ownership: update_file_ownership: new_pkg=aziotctl
> wants file
> /work/build/tmp-glibc/work/eg600-WelotecGmbH-linux/welotec-base-image/1.0-r0/rootfs/etc/aziot/,
> from owner=<NULL>
> update_file_ownership: update_file_ownership: new_pkg=aziotctl
> wants file
> /work/build/tmp-glibc/work/eg600-WelotecGmbH-linux/welotec-base-image/1.0-r0/rootfs/etc/aziot/config.toml,
> from owner=<NULL>
> update_file_ownership: update_file_ownership: new_pkg=aziotctl
> wants file
> /work/build/tmp-glibc/work/eg600-WelotecGmbH-linux/welotec-base-image/1.0-r0/rootfs/usr/,
> from owner=<NULL>
> update_file_ownership: update_file_ownership: new_pkg=aziotctl
> wants file
> /work/build/tmp-glibc/work/eg600-WelotecGmbH-linux/welotec-base-image/1.0-r0/rootfs/usr/bin/,
> from owner=<NULL>
> update_file_ownership: update_file_ownership: new_pkg=aziotctl
> wants file
> /work/build/tmp-glibc/work/eg600-WelotecGmbH-linux/welotec-base-image/1.0-r0/rootfs/usr/bin/aziotctl,
> from owner=<NULL>
> pkg_run_script: Offline root mode: not running aziotctl.preinst.
> ar->extract_flags: 255
> opkg_install_pkg: Installing maintainer scripts.
> print_paths: Extracting
> '/work/build/tmp-glibc/work/eg600-WelotecGmbH-linux/welotec-base-image/1.0-r0/rootfs//var/lib/opkg/info/aziotctl.control'.
> print_paths: Extracting
> '/work/build/tmp-glibc/work/eg600-WelotecGmbH-linux/welotec-base-image/1.0-r0/rootfs//var/lib/opkg/info/aziotctl.preinst'.
> opkg_install_pkg: Installing data files for aziotctl.
> install_data_files: Extracting data files to
> /work/build/tmp-glibc/work/eg600-WelotecGmbH-linux/welotec-base-image/1.0-r0/rootfs/.
> ar->extract_flags: 255
> print_paths: Extracting
> '/work/build/tmp-glibc/work/eg600-WelotecGmbH-linux/welotec-base-image/1.0-r0/rootfs/etc/'.
> print_paths: Extracting
> '/work/build/tmp-glibc/work/eg600-WelotecGmbH-linux/welotec-base-image/1.0-r0/rootfs/etc/aziot/'.
> print_paths: Extracting
> '/work/build/tmp-glibc/work/eg600-WelotecGmbH-linux/welotec-base-image/1.0-r0/rootfs/etc/aziot/config.toml'.
> print_paths: Extracting
> '/work/build/tmp-glibc/work/eg600-WelotecGmbH-linux/welotec-base-image/1.0-r0/rootfs/usr/'.
> print_paths: Extracting
> '/work/build/tmp-glibc/work/eg600-WelotecGmbH-linux/welotec-base-image/1.0-r0/rootfs/usr/bin/'.
> print_paths: Extracting
> '/work/build/tmp-glibc/work/eg600-WelotecGmbH-linux/welotec-base-image/1.0-r0/rootfs/usr/bin/aziotctl'.
> install_data_files: Calling pkg_write_filelist.
> pkg_write_filelist: Creating
> /work/build/tmp-glibc/work/eg600-WelotecGmbH-linux/welotec-base-image/1.0-r0/rootfs//var/lib/opkg/info/aziotctl.list
> file for pkg aziotctl.
> ar->extract_flags: 255
> opkg_install_pkg: Resolving conf files for aziotctl
> opkg_install_pkg: pkg=aziotctl old_state_flag=10 state_flag=0
> opkg_configure_packages: Offline root mode: not configuring
> unpacked packages.
> write_status_files_if_changed: Writing status file.
> pkg_write_changed_filelists: Saving changed filelists.
> hash_table: pkg-hash, 24576 bytes
>         n_buckets=1024, n_elements=11, n_collisions=0
>         max_bucket_len=0, n_used_buckets=11, ave_bucket_len=1.00
>         n_hits=2, n_misses=13
> hash_table: file-hash, 24576 bytes
>         n_buckets=1024, n_elements=6, n_collisions=0
>         max_bucket_len=0, n_used_buckets=6, ave_bucket_len=1.00
>         n_hits=2, n_misses=12
> hash_table: obs-file-hash, 1536 bytes
>         n_buckets=64, n_elements=0, n_collisions=0
>         max_bucket_len=0, n_used_buckets=0, ave_bucket_len=0.00
>         n_hits=0, n_misses=6
>
> As you can see extract_flags are 255 so I am absolutely sure that
> they are set properly ARCHIVE_EXTRACT_ACL, ARCHIVE_EXTRACT_FFLAGS
> and ARCHIVE_EXTRACT_XATTR attributes.
>
> IMHO this is really odd I do not see even this warning you have
> given. Additionally as i said calling *ar -x
> aziotctl_1.4.3.0+cfa39b58ec-r0_core2-64.ipk* and than calling *tar

> --acls --xattrs -xpp data.tar.xz -C rootfs* works.
>

> BR
> Piotr

>
> wt., 4 kwi 2023 o 17:38 Alex Stewart <alex.s...@ni.com> napisał(a):
>
> I'm noticing quite a few places in the un-archive code where
> useful
> warnings are emitted. Could you enable debug output and check
> the logs
> for errors related to setting the disk options when creating
> the output
> archive object [1]?
>
> [1]
> https://git.yoctoproject.org/opkg/tree/libopkg/opkg_archive.c#n373

> <https://urldefense.com/v3/__https://git.yoctoproject.org/opkg/tree/libopkg/opkg_archive.c*n373__;Iw!!FbZ0ZwI3Qg!uSi6BqMd5SzZ6yqJUXgb-0TmiV_Hk2JTJMfSi5oWpvH8W3RzaqOYAbfsiG26gCLideiQtorEa5cnwujzgPQ$>

>
> On 4/4/23 09:59, Piotr Łobacz wrote:
> > OK I have verified that going to devshell for my yocto image
> recipe
> > and extracting this particular ipk package, which has these
> ACLs
> > preserved with *ar -x package.ipk* and than calling *tar --acls
> > --xattrs -xpp data.tar.xz -C rootfs* works.
> >
> > I have also verified the *opkg install -o / package.ipk*
> command on
> > the dedicated device and it does work either.
> >
> > I double checked the opkg-native code and it has my patch
> applied so I
> > really do not know what happens there. Any ideas?
> > wtorek, 4 kwietnia 2023 o 02:10:50 UTC+2 Piotr Łobacz
> napisał(a):
> >
> >     Hi team, I'm recently dealing with turning on support
> for acls as
> >     libarchive already has it  and I have also discovered
> that there
> >     is already commented code in
> >
> https://git.yoctoproject.org/opkg/tree/libopkg/opkg_archive.c#n909

> <https://urldefense.com/v3/__https://git.yoctoproject.org/opkg/tree/libopkg/opkg_archive.c*n909__;Iw!!FbZ0ZwI3Qg!uSi6BqMd5SzZ6yqJUXgb-0TmiV_Hk2JTJMfSi5oWpvH8W3RzaqOYAbfsiG26gCLideiQtorEa5cnr1pADjg$>

> >   
>  <https://urldefense.com/v3/__https://git.yoctoproject.org/opkg/tree/libopkg/opkg_archive.c*n909__;Iw!!FbZ0ZwI3Qg!vkxMexF2VxZOP-KnG8Bo-4GUU9z4v9bsMeEuzM_CByCLL-0AmCQl7izjQ8FdICfHCvWoHKpZKhesu_oic2Q$>
> >
> >     Adding these extra attributes adds support when I do
> install on
> >     the device where opkg is installed. The problem occurs
> when I'm
> >     building an image with yocto kirkstone and there is this
> command
> >
> https://git.openembedded.org/openembedded-core/tree/meta/lib/oe/package_manager/ipk/__init__.py#n368

> <https://urldefense.com/v3/__https://git.openembedded.org/openembedded-core/tree/meta/lib/oe/package_manager/ipk/__init__.py*n368__;Iw!!FbZ0ZwI3Qg!uSi6BqMd5SzZ6yqJUXgb-0TmiV_Hk2JTJMfSi5oWpvH8W3RzaqOYAbfsiG26gCLideiQtorEa5cn-UfHbe8$>

> <mailto:opkg-devel%2Bunsu...@googlegroups.com>.

> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/opkg-devel/71fe2abe-01db-459e-b755-c8c934f579abn%40googlegroups.com

> <https://urldefense.com/v3/__https://groups.google.com/d/msgid/opkg-devel/71fe2abe-01db-459e-b755-c8c934f579abn*40googlegroups.com__;JQ!!FbZ0ZwI3Qg!uSi6BqMd5SzZ6yqJUXgb-0TmiV_Hk2JTJMfSi5oWpvH8W3RzaqOYAbfsiG26gCLideiQtorEa5cnekGUq3c$>
>
> >
> <https://urldefense.com/v3/__https://groups.google.com/d/msgid/opkg-devel/71fe2abe-01db-459e-b755-c8c934f579abn*40googlegroups.com?utm_medium=email&utm_source=footer__;JQ!!FbZ0ZwI3Qg!vkxMexF2VxZOP-KnG8Bo-4GUU9z4v9bsMeEuzM_CByCLL-0AmCQl7izjQ8FdICfHCvWoHKpZKhes_8JzGYw$

[Alex Stewart]

On 4/6/23 02:57, Piotr Łobacz wrote:
> Hi allex I have finally fixed the issue:) the problem was with
> enabling acls in libarchive - they were never set :D no matter that I
> have set them in DISTRO_DEFAULTS.
>
> It appears that yocto has this extra parameter for native environment
> called DISTRO_FEATURES_NATIVE. When I have set it it works perfectly fine.

Ah. So you had set the libarchive bitmask in the opkg code to use ACLs
(et c.), but hadn't enabled that feature in the actual libarchive
library on-disk.

For someone scanning this thread in the future: What DISTRO_FEATURES did
you have to add to enable those extended features in libarchive?

> It appears that yocto has this extra parameter for native environment
> called DISTRO_FEATURES_NATIVE. When I have set it it works perfectly fine.

That makes sense. When executing the do_rootfs stages of your image
recipe, bitbake's toolchain (including the version of libarchive that it
is using to affect the extraction) would come from your
libarchive-native recipe. The non-native version of libarchive is what
gets installed into the target rootfs.

So if you haven't already, I expect you will need to enable those
extended libarchive features in *both* the native and non-native
libarchive recipes for your usecase.

> Btw. I think that we should think of creation a task for putting this
> implementation into opkg and yocto as well.

Is it common for libarchive to be distributed without ACL support
enabled? If it is, we should probably keep the current behavior (not
extracting ACLs) as the default, and let builders enable it for special
cases like yours.

Otherwise, I have no objection to adding support for this case.

> I would be pleased in helping you to apply it all together :)

It sounds like you already have an opkg code patch to add the bitmask
flags. Could you investigate the default state of libarchive from my
question above and modify your patch to be a build-time configuration
(if appropriate)? I'd be happy to accept it via this mailing list.

>
> BR
> Piotr

> <https://urldefense.com/v3/__https://git.yoctoproject.org/opkg/tree/libopkg/opkg_archive.c*n373__;Iw!!FbZ0ZwI3Qg!p3O-73TcRo48GW-QmGfjBiKphjCLe7QWOSRoSuQagMs6EyBH_Nu5j2yeE5rHWVcBggXj7RcdBgSPRp_9kW0$>

> <https://urldefense.com/v3/__https://git.yoctoproject.org/opkg/tree/libopkg/opkg_archive.c*n909__;Iw!!FbZ0ZwI3Qg!p3O-73TcRo48GW-QmGfjBiKphjCLe7QWOSRoSuQagMs6EyBH_Nu5j2yeE5rHWVcBggXj7RcdBgSPX01Rx8M$>

> >       
>  <https://urldefense.com/v3/__https://git.yoctoproject.org/opkg/tree/libopkg/opkg_archive.c*n909__;Iw!!FbZ0ZwI3Qg!uSi6BqMd5SzZ6yqJUXgb-0TmiV_Hk2JTJMfSi5oWpvH8W3RzaqOYAbfsiG26gCLideiQtorEa5cnr1pADjg$>
> >         >
> >       
>   <https://urldefense.com/v3/__https://git.yoctoproject.org/opkg/tree/libopkg/opkg_archive.c*n909__;Iw!!FbZ0ZwI3Qg!vkxMexF2VxZOP-KnG8Bo-4GUU9z4v9bsMeEuzM_CByCLL-0AmCQl7izjQ8FdICfHCvWoHKpZKhesu_oic2Q$>
> >         >
> >         >     Adding these extra attributes adds support when I do
> >         install on
> >         >     the device where opkg is installed. The problem occurs
> >         when I'm
> >         >     building an image with yocto kirkstone and there
> is this
> >         command
> >         >
> >
> https://git.openembedded.org/openembedded-core/tree/meta/lib/oe/package_manager/ipk/__init__.py#n368

> <https://urldefense.com/v3/__https://git.openembedded.org/openembedded-core/tree/meta/lib/oe/package_manager/ipk/__init__.py*n368__;Iw!!FbZ0ZwI3Qg!p3O-73TcRo48GW-QmGfjBiKphjCLe7QWOSRoSuQagMs6EyBH_Nu5j2yeE5rHWVcBggXj7RcdBgSPLP5iJWc$>

> >         <mailto:opkg-devel%2Bunsu...@googlegroups.com
> <mailto:opkg-devel%252Buns...@googlegroups.com>>.

> >         > To view this discussion on the web visit
> >         >
> >
> https://groups.google.com/d/msgid/opkg-devel/71fe2abe-01db-459e-b755-c8c934f579abn%40googlegroups.com

> <https://urldefense.com/v3/__https://groups.google.com/d/msgid/opkg-devel/71fe2abe-01db-459e-b755-c8c934f579abn*40googlegroups.com__;JQ!!FbZ0ZwI3Qg!p3O-73TcRo48GW-QmGfjBiKphjCLe7QWOSRoSuQagMs6EyBH_Nu5j2yeE5rHWVcBggXj7RcdBgSPDXPwfuI$>

[Alex Stewart]

On 4/6/23 14:31, Piotr Łobacz wrote:
> Hi Alex,
> in reply to you questions

>
> > For someone scanning this thread in the future: What DISTRO_FEATURES
> did
> > you have to add to enable those extended features in libarchive?

> acl and xattr

>
> > Ah. So you had set the libarchive bitmask in the opkg code to use ACLs
> > (et c.), but hadn't enabled that feature in the actual libarchive
> > library on-disk.

> Yes, and there is also this thread
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=9858
> <https://urldefense.com/v3/__https://bugzilla.yoctoproject.org/show_bug.cgi?id=9858__;!!FbZ0ZwI3Qg!qjn691Bm_SJqsKVNsDPqoFMe9YKX79Wh_5CWrSpc5eIPSeKng__VqFMLm6LtwtJK-pgBpfmDYF7U_yOZV0Y$>
> to which I would like you to join to discuss the problem, because as I
> have already written
> setting these DISTRO_FEATURES is not enough, they should be set as
> well for native env
> and I have no idea what would be ideal.

That thread is a little confused between the original filer's request to
enable xattrs and acl in the context of a do_install, and your desire to
enable it in the context of libarchive.

I think your patch here [1] seems fine. Though I would expect some
discussion in the commit summary about why the original recipe source
specifically used `class-target`.

[1]
https://lists.openembedded.org/g/openembedded-core/message/179627?p=%2C%2C%2C20%2C0%2C0%2C0%3A%3Acreated%2C0%2Clibarchive%3A+remove+acls%2C20%2C2%2C0%2C98033657

> > Is it common for libarchive to be distributed without ACL support
> > enabled? If it is, we should probably keep the current behavior (not
> > extracting ACLs) as the default, and let builders enable it for special
> > cases like yours.

> It is and it's already in libarchive recipe to enable these features
> but right
> now it is only for target build. I have posted my patch to the yocto
> but Richard
> stated that these patches are for kikrstone not the master and won't
> be added
> as a new feature...

I think Richard was just asking you to rebase your changes to the OE
master ref and do your testing there. It won't be cherry-picked back to
the kirkstone stable, but you can do the cherry-pick to your local
kirkstone fork.

> > It sounds like you already have an opkg code patch to add the bitmask
> > flags. Could you investigate the default state of libarchive from my
> > question above and modify your patch to be a build-time configuration
> > (if appropriate)? I'd be happy to accept it via this mailing list.

> I have already given them to bugzila thread
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=15097
> <https://urldefense.com/v3/__https://bugzilla.yoctoproject.org/show_bug.cgi?id=15097__;!!FbZ0ZwI3Qg!qjn691Bm_SJqsKVNsDPqoFMe9YKX79Wh_5CWrSpc5eIPSeKng__VqFMLm6LtwtJK-pgBpfmDYF7UVv-wZPI$>
> but as I have written I have no experience with autoconf...

There are realistically no developers available to execute on
miscellaneous feature requests like this. I try to allocate some
bandwidth from NI to close opkg issues, but I have to focus on
more-urgent bugs. So if you aren't able to implement the feature, then
it will probably sit in the backlog indefinitely.

And without a pathway to upstream your opkg commits, I don't think I can
support adding .patches to the OE-core opkg recipe. I think you would
have to carry your changes out of stream; obviously that isn't ideal.

I would recommend that we work to get your changes upstream in okpg
first, and then you will have a cleaner argument for a patchset to OE-core.

>
> BR
> Piotr

> <https://urldefense.com/v3/__https://git.yoctoproject.org/opkg/tree/libopkg/opkg_archive.c*n373__;Iw!!FbZ0ZwI3Qg!qjn691Bm_SJqsKVNsDPqoFMe9YKX79Wh_5CWrSpc5eIPSeKng__VqFMLm6LtwtJK-pgBpfmDYF7Ups2pqHw$>

> <https://urldefense.com/v3/__https://git.yoctoproject.org/opkg/tree/libopkg/opkg_archive.c*n909__;Iw!!FbZ0ZwI3Qg!qjn691Bm_SJqsKVNsDPqoFMe9YKX79Wh_5CWrSpc5eIPSeKng__VqFMLm6LtwtJK-pgBpfmDYF7UAWhGn9Q$>

> >   
>  <https://urldefense.com/v3/__https://git.yoctoproject.org/opkg/tree/libopkg/opkg_archive.c*n909__;Iw!!FbZ0ZwI3Qg!p3O-73TcRo48GW-QmGfjBiKphjCLe7QWOSRoSuQagMs6EyBH_Nu5j2yeE5rHWVcBggXj7RcdBgSPX01Rx8M$>
> >     >
> >   
>   <https://urldefense.com/v3/__https://git.yoctoproject.org/opkg/tree/libopkg/opkg_archive.c*n909__;Iw!!FbZ0ZwI3Qg!uSi6BqMd5SzZ6yqJUXgb-0TmiV_Hk2JTJMfSi5oWpvH8W3RzaqOYAbfsiG26gCLideiQtorEa5cnr1pADjg$>
> >     >         >
> >     >
> >   
>    <https://urldefense.com/v3/__https://git.yoctoproject.org/opkg/tree/libopkg/opkg_archive.c*n909__;Iw!!FbZ0ZwI3Qg!vkxMexF2VxZOP-KnG8Bo-4GUU9z4v9bsMeEuzM_CByCLL-0AmCQl7izjQ8FdICfHCvWoHKpZKhesu_oic2Q$>
> >     >         >
> >     >         >     Adding these extra attributes adds support
> when I do
> >     >         install on
> >     >         >     the device where opkg is installed. The
> problem occurs
> >     >         when I'm
> >     >         >     building an image with yocto kirkstone and there
> >     is this
> >     >         command
> >     >         >
> >     >
> >
> https://git.openembedded.org/openembedded-core/tree/meta/lib/oe/package_manager/ipk/__init__.py#n368

> <https://urldefense.com/v3/__https://git.openembedded.org/openembedded-core/tree/meta/lib/oe/package_manager/ipk/__init__.py*n368__;Iw!!FbZ0ZwI3Qg!qjn691Bm_SJqsKVNsDPqoFMe9YKX79Wh_5CWrSpc5eIPSeKng__VqFMLm6LtwtJK-pgBpfmDYF7UNqW7RxU$>

> >     >         <mailto:opkg-devel%2Bunsu...@googlegroups.com
> <mailto:opkg-devel%252Buns...@googlegroups.com>
> >     <mailto:opkg-devel%252Buns...@googlegroups.com
> <mailto:opkg-devel%25252Bun...@googlegroups.com>>>.

> >     >         > To view this discussion on the web visit
> >     >         >
> >     >
> >
> https://groups.google.com/d/msgid/opkg-devel/71fe2abe-01db-459e-b755-c8c934f579abn%40googlegroups.com

> <https://urldefense.com/v3/__https://groups.google.com/d/msgid/opkg-devel/71fe2abe-01db-459e-b755-c8c934f579abn*40googlegroups.com__;JQ!!FbZ0ZwI3Qg!qjn691Bm_SJqsKVNsDPqoFMe9YKX79Wh_5CWrSpc5eIPSeKng__VqFMLm6LtwtJK-pgBpfmDYF7UVk9Ns_Q$>