Re: [docs] "FILES" glossary entry does not mention including "dirname/*"

On Wed, 10 Jun 2026, Quentin Schulz wrote:

> Hi Robert,
>
> On 5/29/26 1:00 PM, Robert P. J. Day via lists.yoctoproject.org wrote:
> >
> >    explaining to a colleague how to properly define a package's
> > "FILES:${PN}" value, and noticed that the explanation here:
> >
> >    https://docs.yoctoproject.org/ref-manual/variables.html#term-FILES
> >
> > has a subtle distinction from the default value in bitbake.conf. in
> > the glossary, the sample setting:
> >
> >    FILES:${PN} += "${bindir}/mydir1 ${bindir}/mydir2/myfile"
> >
> > shows how to include an entire directory -- just list the directory
> > name and the inclusion is recursive.
> >
> >    my colleague had initially used the notation "dirname/*", and i
> > pointed out that the "*" wildcard was superfluous since, you know,
> > recursive, but he showed me the sample he had used from bitbake.conf,
> > which *does* include that wildcard:
> >
> >    FILES:${PN} = "${bindir}/* ${sbindir}/* ${libexecdir}/* ...
> >
> > i couldn't immediately explain why bitbake.conf used the wildcard, as
> > the only difference i could imagine is that explicitly using the "*"
> > wildcard would ignore hidden paths, but that seemed like a weak
> > explanation.
> >
> >    is there some subtlety i'm missing?
> >
>
> Did you ever figure this one out?
>
> I started to look into it quickly because I vaguely remember some gotchas
> around including directories and symlinks we ran into at my previous company
> years ago.
>
> I'm assuming you want to have a look at populate_packages() in
> meta/lib/oe/package.py.
> It'll eventually call oe.package.files_from_filevars() which runs
> glob.glob(path, recursive=True) on each path. The issue is that:
>
> >>> import glob
> >>> glob.glob('./tools/', recursive=True)
> ['./tools/']
> >>> glob.glob('./tools', recursive=True)
> ['./tools']
> >>> glob.glob('./tools/*', recursive=True)
> ['./tools/accounting', './tools/arch', './tools/bootconfig', './tools/bpf',
> './tools/build', './tools/cgroup', './tools/counter', './tools/debugging',
> './tools/firewire', './tools/firmware', './tools/gpio', './tools/hv',
> './tools/iio', './tools/include', './tools/kvm', './tools/laptop',
> './tools/leds', './tools/lib', './tools/memory-model', './tools/objtool',
> './tools/pci', './tools/pcmcia', './tools/perf', './tools/power',
> './tools/rcu', './tools/scripts', './tools/spi', './tools/testing',
> './tools/thermal', './tools/time', './tools/tracing', './tools/usb',
> './tools/virtio', './tools/wmi', './tools/Makefile', './tools/certs',
> './tools/crypto', './tools/mm', './tools/net', './tools/sched_ext',
> './tools/sound', './tools/verification', './tools/workqueue',
> './tools/writeback']
>
> and I cannot make sense of the rest of the logic in populate_packages() which
> checks whether the path is a directory, and if so, seemingly only runs a
> homegrown version of mkdir -p. Something's not adding up here.
>
> Note that glob.glob() doesn't return hidden files by default, c.f.
> https://docs.python.org/3/library/glob.html#glob.glob (feature only added in
> Python 3.11 anyway, which we haven't set as our minimally supported version).

  I'd totally forgotten about this, so I just did a test and got the
same weirdness so I checked the docs:

https://docs.python.org/3/library/glob.html

"If recursive is true, the pattern “**” will match any files and zero
or more directories, subdirectories and symbolic links to
directories..."

  The way I read that, the recursive parameter has an effect only when
you're using the "**" pattern, and would appear to have no value here.
So it seems you definitely need the trailing "/*" to get directory
contents.

rday