When a library package specifies additional provides, e.g. libncurses
which provides libncursesw, we should also append the abi version
suffix to each provide, since there may be more than one package
providing the virtual library.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
Subdequent commits need this information to resolve the ABI version when
computing binary ipk dependencies.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
Subsequent commits will put more auxiliary information into this file,
such as the per-package ABI version, so rename the metadata script
subcommand and file names accordingly.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
Prevent emitting broken dependency statements when resolving references
to non existing packages to an empty provider list.
Fixes: 47d6b05ad3 ("metadata: always resolve dependencies through provides list")
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
Package "features" seem to be unused for some time. In any case, custom
Config.in snippets and package PROVIDES are a much more flexible way to
express similar options.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
Instead of adding virtual packages to the normal package list, keep a
separate list for provides, make each package provide itself, and resolve
all dependencies through this list. This allows to use PROVIDES to replace
existing packages.
Fixes FS#837.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
Runtime depends cannot have a buildtype suffix, and they never refer to
source package names. In addition, this adds warnings about unsatisfiable
dependencies.
Furthermore, this change fixes the generation of conditional build
dependencies for virtual packages provided by different source packages.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
Target build depends are similar to host build depends in that they refer
to source packages rather than binary packages. Therefore, it makes sense
to handle them together, rather than putting them in a list together with
runtime depends and trying to figure out if the entries refer to source or
to binary packages afterwards.
This does lead to PKG_BUILD_DEPENDS entries referring to binary package
names not working anymore, which requires some fixes in the package
repositories.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
This feature has been unused for years, and its scope is too limited to be
actually useful.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
Every single reference to subdir was concatenated with the source package
name, so it makes sense to store the concatenated value instead.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
We often want to access fields of a source packages through pkg->{src}.
Allow accessing them directly instead of resolving the source hash through
srcpackages.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
All build dependencies are between source packages. Interating over source
rather than binary packages simplifies parts of the code and prepares
further improvement.
As a side effect, this changes the implicit default variant of a few
packages (the first defined is used now instead of the lexicographically
first).
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
Build types are a property of source rather than binary packages. This is a
preparation for followup cleanup.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
Turn the srcpackage values into hashes to allow storing more information
than just binary package names.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
Nothing explicitly depends on base-files, and even if it would, it would
not cause any problems. Remove the unused special case.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
A self-dependency is not an error worth a warning; rather, it is very
common: whenever there are dependencies between different binary packages
originating from the same source package, such dependencies occur. Not
actually generating dependency rules is correct, but already handled a few
lines below.
A typo prevented this redundant rule from working, which is the reason the
warning was not actually printed.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
When a package declares a PKG_BUILD_DEPENDENCY or HOST_BUILD_DEPENDENCY on
a not existing build type, the metadata script will emit a reference to an
unresolvable build target in tmp/.packagedeps, causing the make process to
fail hard in a way not catchable by the IGNORE_ERRORS mechanism.
In a situation where a package "test-a" declares a build dependency
"PKG_BUILD_DEPENDS:=test-b/host" while the Makefile of "test-b" does not
implement a HostBuild, make fails with an unrecoverable error in the form:
make[1]: Entering directory '...'
make[1]: *** No rule to make target 'package/test-b/host/compile',
needed by 'package/test-a/compile'. Stop.
make[1]: Leaving directory '...'
.../toplevel.mk:200: recipe for target 'package/test-a/compile' failed
make: *** [package/test-a/compile] Error 2
Extend the metadata generation script to catch such unresolved references
and emit a visable warning upon detection.
After this change, the script will emit a warning similar to:
WARNING: Makefile "package/test-a/Makefile" has a build dependency on
"test-b/host" but "package/test-b/Makefile" does not implement a
"host" build type
Fixes a global build cluster outage which occured after the "python-cffi"
feed package removed its HostBuild which the "python-cryptography" package
build-depended on.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
The script will now detect uid/gid collision and can generate a table of
current allocation
./scripts/package-metadata.pl usergroup tmp/.packageinfo \
| sort -k 1,1r -k 3,3n \
| column -t
This should ensure that no collision will happen for each single build
Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com>
Conditional dependencies use the '(!cond) || dep' syntax, whereas
conditional select uses 'dep if cond'.
Add an extra check to suppress emitting a conditional if an equal
conditional select already exists.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
So far, package-metadata.pl always considered the first provider of a virtual
package to be the default variant which might deviate from what buildroot
considers to be the default.
Change the Kconfig dependency / select code generation for virtual package
providers to consider the DEFAULT_VARIANT to be the primary provider and only
fall back to the first provider if no default variant was explicitely tagged.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
Currently the code emitting dependencies for provide candidates is overwriting
the specification calculated by the previous conditional dependency handling
code, rendering dependencies on virtual PROVIDES packages in conjunction with
conditional dependencies unusable.
Instead of overwriting, append the PROVIDES dependency spec in order to fix
using DEPENDS on virtual provider packages in conjunction with conditions.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
If core packages are overridden, CONFIG_OVERRIDE_PKGS is set
based on the scan order of packages, which eventually causes
that config value to be modified on each build and with
that causes the build process to warn for configuration
being out of sync.
This commit changes the CONFIG_OVERRIDE_PKGS to be sorted
and prevents that false warning.
Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
Dependencies on purely virtual packages (satisfied by PROVIDES) that were
not using "selects" ("+" flag) would be prepended with the prefix
"PACKAGE_" twice, breaking the first alternative.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
Instead of ignoring all metadata for package/kernel/linux, process it
and only suppress emitting config data to tmp/.config-package.in
This ensures that packages that select kmod-* packages can inherit their
depdendencies.
Signed-off-by: Felix Fietkau <nbd@nbd.name>