| Age | Commit message (Collapse) | Author | Files |
|---|
|
usefull for splitting out libraries
|
|
empty packages
|
|
|
|
|
|
Kernel-modules which end with -dev get update-modules-dev
as RRECOMMENDS so update-modules-dev gets pulled in images.
So we blacklist kernel-module packages for now.
|
|
(from poky)
|
|
strip...
|
|
|
|
base.bbclass and add shell version
|
|
pkgconfig code.
|
|
|
|
* This helps uclibc systems where ldconfig is optional, in particular 3rd-party
systems like OpenWRT.
* Per RFC on the list.
|
|
packages this doesn't change much but for cross/sdk/native packages the distinction is important (from poky)
|
|
whole functionality ideally needs rewriting but this fixes various important issues with SDK generation
|
|
Also replace long since unused old_shlibs_dir (from poky)
|
|
version from bitbake now
|
|
the package task doesn't create chains of .debug directories (from poky)
|
|
ASSUME_PROVIDED.
* List of <shlib_file_name>:<package>[_<version>] mappings. This info will
be appended to one inferred by automatic shlib tracking code. So, it would be
possible to have correct package dependencies even for libraries in
ASSUME_PROVIDED.
|
|
functionality in a multimachine safe way instead (from poky).
|
|
packaged function from base.bbclass rather than our own (from poky)
|
|
using ALLOW_EMPTY instead of ALLOW_EMTPY_pkg (from poky)
|
|
- do not transform a symlink to a directory into a directory on copy
- preserve the mode when copying a directory
|
|
of moving files (from poky). The copyfile function will be moved to bitbake in due course.
|
|
New file: packages/mono/mono-mcs-intermediate_1.2.5.1.bb
Compiles mono in native mode with standard prefix, then tars up the
resulting tree and puts the tarfile into staging
New file: packages/mono/mono_files.py
Automatically generated using collect-path.py (attached to this mail)
and contains a list that maps file patterns to package names (and
contained assemblies, see below).
New file: classes/mono.bbclass
Has a helper function for the list that maps file patterns to package
names and assemblies (see below). Also has a function mono_do_clilibs
and inserts that function into PACKAGEFUNCS. This function calls
mono_find_provides_and_requires which finds out (through calls to
monodis --assembly and monodis --assemblyref) which assemblies are
provided and required by a particular package. mono_do_clilibs then
puts the information about provided assemblies into
${STAGING_DIR}/clilibs/${packagename}.list and information about the
required packages into ${PKGDEST}/{packagename}.clilibdeps where it
will later be picked up by the modified read_shlibdeps.
Originally I had dependency resolution through the partial list in
mono_files.py but obviously this doens't scale, so I implemented the
new method with mono_do_clilibs. The benefit is now that I don't really
need the extra information in mono_files.py anymore and can in
principle get rid of mono_get_file_table and related code. Instead it
should be possible to modify collect-paths.py to output bitbake .inc
code (e.g. PACKAGES = "..." and a whole lot of FILES_... = "...")
instead of python code. There's still the minor problem of how to
handle the .mdb files, that's why I didn't implement it yet but instead
opted for an approach that I knew would work. (Debian just puts
the .mdb files into the individual packages, while I would argue that
they do belong into corresponding -dbg packages.)
Modified file: classes/package.bbclass
In read_shlibdeps I folded the two identical code blocks dealing with
*.shlibdeps and *.pcdeps into one and added *.clilibdeps (generated by
mono_do_clilibs above).
Modified file: packages/mono/mono_1.2.5.1.bb
Add the mono-mcs-intermediate workaround. Add a whole lot of python
code in populate_packages_prepend in order to split up the packages
based on information from mono_files.py (via mono.bbclass'
mono_get_file_table). As I said above a lot of this code can hopefully
be replaced in the future.
|
|
up/optimise PACKAGES checks a bit
|
|
some unneeded complexity (from poky)
|
|
|
|
|
|
|
|
when multiple -dev or -dbg packages are generated and when a single one is generated (from poky)
|
|
|
|
certain dependency chainhandling in both ipkg and dpkg (from poky)
|
|
generate (PACKAGES != ) removing needless dependencies (from poky)
|
|
correct operation with bitbake 1.8.x. Old behaviour is maintained in a special legacy anonymous function in base.bbclass. The patch is an improved version of the one discussed on the mailing list.
|
|
|
|
- if package contain libraries which are not used outside then add PRIVATE_LIBS
variable with names of them to not generate shlibs for them.
|
|
"inherit package_ipk package_tar" and seems to interfere with do_split_packages
|
|
|
|
|
|
causing python
traceback spew during population
|
|
migration
|
|
|
|
I do not know does this is best way of fixing it but it is better to have it in
repository then having rootfs images without libc.
|
|
${HOST_PREFIX}objdump
package.bbclass : make use of the OBJDUMP variable rather than
calling ${BUILD_PREFIX}objdump inside do_shlibs. As the original
usage was faulty and ended up calling host objdump which works
for some arm targets but not all.
|
|
RRECOMMENDS, from Poky
* poky rev 823: 'package.bbclass: depchains: don't -destructively- set the pkg's RRECOMMENDS.'
* poky rev 824: 'base.bbclass: depchains: don't -destructively- set the pkg's RRECOMMENDS.'
|
|
packages. The way it selects the principle package name needs totally reworking as the current code is flawed but apply a workaround for now (this is unrelated to other changes to package.bbclass)
|
|
packages. The way it selects the principle package name needs totally reworking as the current code is flawed but apply a workaround for now (this is unrelated to other changes to package.bbclass)
|
|
then package_write which actually generates the packages. The two stage approach allows us to avoid circular dependency issues from classes like debian.bbclass. As the data being emitted into pkgdata/ changed, you need to either wipe tmp or rerun the do_package tasks (wipe the do_package stamps). Everything will repackage anyway due to the new task.
|
|
functional changes (from poky)
|
|
barfing
package.bbclass: likewise
|
