DPKG Issue - guidance neede

DPKG Issue - guidance neede

[patrick.vogelaar.dev]

Hi all,

we are building a custom distribution and are using a shared sstate cache. Now we discovered an edge case where it causes problems if parts of the CIs build path exist but is not accessible due to permissions.

Build path CI: /var/jenkins_home/.../build

If now on my local machine the directory /var/jenkins_home exists but is not accessible due to permissions the build fails in do_rootfs with:
dpkg: error: error opening configuration directory '/var/jenkins_home/.../build/tmp/.../recipe-sysroot-native/etc/dpkg/dpkg.cfg.d': Permission denied

If this directory does not exist dpkg fails silent and there is no problem at all. But if it cannot access it because of permissions it throws an error.

What would the workflow now be?
Provide a patch to the dpkg project and also add the patch to the recipe? or something else?
Should I create a bugzilla issue?
...

Would be great to get some support on the typical next steps.

Thanks for the guidance
Patrick

Re: [OE-core] DPKG Issue - guidance neede

[Alexander Kanavin]

You need to explain why the directory has permissions that don't allow
you to access it. What is the workflow that causes this? Typically
anything in a build directory is built by the user themselves, and
taking a build from another user and reusing it is not supported.
Sstate cache is the correct mechanism to share build output.

Alex

On Fri, 24 Apr 2026 at 07:29, Patrick Vogelaar via
lists.openembedded.org
<patrick.vogelaar.dev=mailbox.org@lists.openembedded.org> wrote:
>
> Hi all,
>
> we are building a custom distribution and are using a shared sstate cache. Now we discovered an edge case where it causes problems if parts of the CIs build path exist but is not accessible due to permissions.
>
> Build path CI: /var/jenkins_home/.../build
>
> If now on my local machine the directory /var/jenkins_home exists but is not accessible due to permissions the build fails in do_rootfs with:
> dpkg: error: error opening configuration directory '/var/jenkins_home/.../build/tmp/.../recipe-sysroot-native/etc/dpkg/dpkg.cfg.d': Permission denied
>
> If this directory does not exist dpkg fails silent and there is no problem at all. But if it cannot access it because of permissions it throws an error.
>
> What would the workflow now be?
> Provide a patch to the dpkg project and also add the patch to the recipe? or something else?
> Should I create a bugzilla issue?
> ...
>
> Would be great to get some support on the typical next steps.
>
> Thanks for the guidance
> Patrick
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#235836): https://lists.openembedded.org/g/openembedded-core/message/235836
> Mute This Topic: https://lists.openembedded.org/mt/118983534/1686489
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alex.kanavin@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

Re: [OE-core] DPKG Issue - guidance neede

[patrick.vogelaar.dev]

Hi Alex,

>  
> You need to explain why the directory has permissions that don't allow
> you to access it. What is the workflow that causes this? Typically
> anything in a build directory is built by the user themselves, and
> taking a build from another user and reusing it is not supported.
> Sstate cache is the correct mechanism to share build output.
> 

Yes, we are using the sstate cache to share the build. Our CI is providing its sstate cache to the developers. The Point is that DPKG compiles in the path of the dpkg config dir into the binary (see [1]). If it does not find this directory (ENOENT) it fails silently. And I guess this is what happens for nearly everybody that uses dpkg-native from a shared sstate cache. So there is no error and it works.

On the CI the build directory is located under /var/jenkins_home/.../build. This means that CONFIGDIR is set to ${sysconfdir}/dpkg which ends up in the binary

But unluckily we had the case that some devs had the directory /var/jenkins_home on their machines present but with permissions not accessible by the build user. Now dpkg-native does not receive a ENOENT but EACCES which does not fail silently anymore and we have shown error message.


For me it is not clear where I should provide a fix or bug report to. Is it:
1. a problem of the sstate cache mechanism because it cannot handle compiled in paths?
2. a problem of the recipe because that path should not go into the binary or be configurable (which would also mean a change in the dpkg source)
3. a problem of dpkg that it should treat EACCES the same as ENOENT or make the config dir configurable as a runtime option. (But I guess that I would need to discuss with the DPKG project)


[1] https://github.com/guillemj/dpkg/blob/1.22.0/lib/dpkg/options.c#L162-L178

Patrick

> 
> Alex
> 
> On Fri, 24 Apr 2026 at 07:29, Patrick Vogelaar via
> lists.openembedded.org
> <patrick.vogelaar.dev=mailbox.org@lists.openembedded.org> wrote:
> >
> > Hi all,
> >
> > we are building a custom distribution and are using a shared sstate cache. Now we discovered an edge case where it causes problems if parts of the CIs build path exist but is not accessible due to permissions.
> >
> > Build path CI: /var/jenkins_home/.../build
> >
> > If now on my local machine the directory /var/jenkins_home exists but is not accessible due to permissions the build fails in do_rootfs with:
> > dpkg: error: error opening configuration directory '/var/jenkins_home/.../build/tmp/.../recipe-sysroot-native/etc/dpkg/dpkg.cfg.d': Permission denied
> >
> > If this directory does not exist dpkg fails silent and there is no problem at all. But if it cannot access it because of permissions it throws an error.
> >
> > What would the workflow now be?
> > Provide a patch to the dpkg project and also add the patch to the recipe? or something else?
> > Should I create a bugzilla issue?
> > ...
> >
> > Would be great to get some support on the typical next steps.
> >
> > Thanks for the guidance
> > Patrick
> >
> > -=-=-=-=-=-=-=-=-=-=-=-
> > Links: You receive all messages sent to this group.
> > View/Reply Online (#235836): https://lists.openembedded.org/g/openembedded-core/message/235836
> > Mute This Topic: https://lists.openembedded.org/mt/118983534/1686489
> > Group Owner: openembedded-core+owner@lists.openembedded.org
> > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alex.kanavin@gmail.com]
> > -=-=-=-=-=-=-=-=-=-=-=-
> >

Re: [OE-core] DPKG Issue - guidance neede

[Alexander Kanavin]

On Fri, 24 Apr 2026 at 18:17, <patrick.vogelaar.dev@mailbox.org> wrote:
> For me it is not clear where I should provide a fix or bug report to. Is it:
> 1. a problem of the sstate cache mechanism because it cannot handle compiled in paths?
> 2. a problem of the recipe because that path should not go into the binary or be configurable (which would also mean a change in the dpkg source)
> 3. a problem of dpkg that it should treat EACCES the same as ENOENT or make the config dir configurable as a runtime option. (But I guess that I would need to discuss with the DPKG project)
>

Typically yocto deals with such hardcoded paths in two ways:
- they can be set to something bogus at build time
("/some/bogus/path"), if there is no use case for reading from those
paths. No one found a use for placing something in CONFIGDIR until
now, so that's probably the case.
- the source code is patched to allow setting an alternative path at
runtime either via command line option or environment variable. E.g.
this is how rpm/dnf are configured. Any such patches should be offered
upstream as well.

I can't guide you further now, but you could look into both options.
Leaving a non-configurable build host-specific path in the binary
isn't right, as the behavior will potentially differ depending on
whether it exists/is readable/etc. or not.

Alex