Support additional user-defined package metadata
cover Support additional user-defined package metadata
I'm an owner of Kindle Touch. It's basically a computer with ARM Cortex-A8 based CPU and Linux. There is a [small] community of enthuasists developing homebrew modifications for stock software. For distributing of these modifications .ipk package format had been chosen with OE as build infrastructure.
There are already several firmware versions for device and some more are expected. Every firmware can introduce unpredictable changes, so modifications for previous firmware versions could stop working.
Custom metadata field with supported firmware version(s) could be included into package control file for preventing of installing packaged modifications onto unsupported firmware.
But OE currently doesn't allow to define additional package metadata in recipes. Patch fixes it.
There is already RPMSPEC_PREAMBLE variable used in package_rpm.bbclass. I think, it is still useful for defining custom macros in header of spec file (while additional user-defined metadata is placed somewhere between common tags).
I didn't found any way to define newline character inside variable value and it is needed to allow multiple [one-line] metadata fields/tags. So I've used ability of OE to split list-typed variables (and re-joined splitted value with real newline character).
The following changes since commit cab85fd0b481cdbf36477348de75352be3f38ca2:
gdk-pixbuf: Drop unneeded RPROVIDES (2012-05-12 11:23:27 +0100)
up to 052d78ed7f986e76afb1ce6ef02e94ba1bbc9719:
package_{ipk, deb, rpm}.bbclass: support additional user-defined metadata (2012-05-13 14:51:26 +0300)
----------------------------------------------------------------
Leonid Borisenko (2):
package.bbclass: add getter of additional metadata package_{ipk, deb, rpm}.bbclass: support additional user-defined metadata
meta/classes/package.bbclass | 11 +++++++++++ meta/classes/package_deb.bbclass | 5 +++++ meta/classes/package_ipk.bbclass | 5 +++++ meta/classes/package_rpm.bbclass | 7 +++++++ 4 files changed, 28 insertions(+)
PATCH v2 1/2 package.bbclass: add getter of additional metadata
Two variables are searched for value of additional package metadata:
* PACKAGE_ADD_METADATA_<PKGTYPE>
* PACKAGE_ADD_METADATA
First found variable with defined value wins.
<PKGTYPE> is a parameter of getter and expected to be a distinct name of specific package type. For example: 'DEB' or 'RPM'.
Variable can contain multiple [one-line] metadata fields, separated by literal sequence '\n'. Separator can be redefined through variable flag 'separator'. Getter returns found value with separator replaced with newline character.
As side-effect, searched variables acquired flags 'type' (equals to 'list') and 'separator'.
--- meta/classes/package.bbclass | 11 +++++++++++ 1 file changed, 11 insertions(+)
meta/classes/package.bbclass +11 -0
@@ -326,6 +326,17 @@ def get_package_mapping (pkg, d): return pkg +def get_package_additional_metadata (pkg_type, d): + base_key = "PACKAGE_ADD_METADATA" + for key in ("%s_%s" % (base_key, pkg_type.upper()), base_key): + if d.getVar(key) is None: + continue + d.setVarFlag(key, "type", "list") + if d.getVarFlag(key, "separator") is None: + d.setVarFlag(key, "separator", "\\n") + metadata_fields = [field.strip() for field in oe.data.typed_value(key, d)] + return "\n".join(metadata_fields).strip() + def runtime_mapping_rename (varname, d): #bb.note("%s before: %s" % (varname, d.getVar(varname, True)))
Signature · 1 line
1.7.10
PATCH v2 2/2 package_{ipk, deb, rpm}.bbclass: support additional user-defined metadata
In reply to Leonid BorisenkoAdditional metadata from user-defined variable is written into control/spec file of binary package.
Three variables are searched for adiitional package metadata:
* PACKAGE_ADD_METADATA_<PKGTYPE>_<PN>
* PACKAGE_ADD_METADATA_<PKGTYPE>
* PACKAGE_ADD_METADATA
First found variable with defined value wins.
<PN> is a package name. <PKGTYPE> is a distinct name of specific package type:
* IPK for .ipk packages
* DEB for .deb packages
* RPM for .rpm packages
Variable can contain multiple [one-line] metadata fields separated by literal sequence '\n'. Separator can be redefined through variable flag 'separator'. In package control/spec file separator is replaced by newline character.
--- meta/classes/package_deb.bbclass | 5 +++++ meta/classes/package_ipk.bbclass | 5 +++++ meta/classes/package_rpm.bbclass | 7 +++++++ 3 files changed, 17 insertions(+)
meta/classes/package_deb.bbclass +5 -0
@@ -330,6 +330,11 @@ python do_package_deb () { raise bb.build.FuncFailed("Missing field for deb generation: %s" % value) # more fields + custom_fields_chunk = get_package_additional_metadata("deb", localdata) + if custom_fields_chunk is not None: + ctrlfile.write(unicode(custom_fields_chunk)) + ctrlfile.write("\n") + mapping_rename_hook(localdata) rdepends = bb.utils.explode_dep_versions(localdata.getVar("RDEPENDS", True) or "")
meta/classes/package_ipk.bbclass +5 -0
@@ -367,6 +367,11 @@ python do_package_ipk () { raise bb.build.FuncFailed("Missing field for ipk generation: %s" % value) # more fields + custom_fields_chunk = get_package_additional_metadata("ipk", localdata) + if custom_fields_chunk is not None: + ctrlfile.write(custom_fields_chunk) + ctrlfile.write("\n") + mapping_rename_hook(localdata) rdepends = bb.utils.explode_dep_versions(localdata.getVar("RDEPENDS", True) or "")
meta/classes/package_rpm.bbclass +7 -0
@@ -638,6 +638,7 @@ python write_specfile () { srcmaintainer = d.getVar('MAINTAINER', True) srchomepage = d.getVar('HOMEPAGE', True) srcdescription = d.getVar('DESCRIPTION', True) or "." + srccustomtagschunk = get_package_additional_metadata("rpm", d) srcdepends = strip_multilib(d.getVar('DEPENDS', True), d) srcrdepends = []
@@ -691,6 +692,7 @@ python write_specfile () { splitlicense = (localdata.getVar('LICENSE', True) or "") splitsection = (localdata.getVar('SECTION', True) or "") splitdescription = (localdata.getVar('DESCRIPTION', True) or ".") + splitcustomtagschunk = get_package_additional_metadata("rpm", localdata) translate_vers('RDEPENDS', localdata) translate_vers('RRECOMMENDS', localdata)
@@ -759,6 +761,9 @@ python write_specfile () { spec_preamble_bottom.append('License: %s' % splitlicense) spec_preamble_bottom.append('Group: %s' % splitsection) + if srccustomtagschunk != splitcustomtagschunk: + spec_preamble_bottom.append(splitcustomtagschunk) + # Replaces == Obsoletes && Provides if splitrreplaces and splitrreplaces.strip() != "": for dep in splitrreplaces.split(','):
@@ -849,6 +854,8 @@ python write_specfile () { spec_preamble_top.append('Group: %s' % srcsection) spec_preamble_top.append('Packager: %s' % srcmaintainer) spec_preamble_top.append('URL: %s' % srchomepage) + if srccustomtagschunk: + spec_preamble_top.append(srccustomtagschunk) source_list = get_tarballs(d) tail_source(d,source_list,None)
Signature · 1 line
1.7.10
Ping. Any comments?
Btw, '[PATCH 0/3]' in subject is my accidental mistake. It shoud be '[PATCH 0/2]'.
Quoted 47 lines · Leonid Borisenko
I'm an owner of Kindle Touch. It's basically a computer with ARM Cortex-A8 based CPU and Linux. There is a [small] community of enthuasists developing homebrew modifications for stock software. For distributing of these modifications .ipk package format had been chosen with OE as build infrastructure.
There are already several firmware versions for device and some more are expected. Every firmware can introduce unpredictable changes, so modifications for previous firmware versions could stop working.
Custom metadata field with supported firmware version(s) could be included into package control file for preventing of installing packaged modifications onto unsupported firmware.
But OE currently doesn't allow to define additional package metadata in recipes. Patch fixes it.
There is already
RPMSPEC_PREAMBLEvariable used in package_rpm.bbclass. I think, it is still useful for defining custom macros in header of spec file (while additional user-defined metadata is placed somewhere between common tags).I didn't found any way to define newline character inside variable value and it is needed to allow multiple [one-line] metadata fields/tags. So I've used ability of OE to split list-typed variables (and re-joined splitted value with real newline character).
The following changes since commit
cab85fd0b481cdbf36477348de75352be3f38ca2:gdk-pixbuf: Drop unneeded RPROVIDES (2012-05-12 11:23:27 +0100)
up to
052d78ed7f986e76afb1ce6ef02e94ba1bbc9719:package_{ipk, deb, rpm}.bbclass: support additional user-defined metadata (2012-05-13 14:51:26 +0300)
----------------------------------------------------------------
Leonid Borisenko (2):
package.bbclass: add getter of additional metadata package_{ipk, deb, rpm}.bbclass: support additional user-defined metadatameta/classes/package.bbclass | 11 +++++++++++
meta/classes/package_deb.bbclass | 5 +++++ meta/classes/package_ipk.bbclass | 5 +++++ meta/classes/package_rpm.bbclass | 7 +++++++ 4 files changed, 28 insertions(+)
v2 cover Support additional user-defined package metadata
In reply to Leonid BorisenkoPing again. Any comments?
Quoted 46 lines · Leonid Borisenko
I'm an owner of Kindle Touch. It's basically a computer with ARM Cortex-A8 based CPU and Linux. There is a [small] community of enthuasists developing homebrew modifications for stock software. For distributing of these modifications .ipk package format had been chosen with OE as build infrastructure.
There are already several firmware versions for device and some more are expected. Every firmware can introduce unpredictable changes, so modifications for previous firmware versions could stop working.
Custom metadata field with supported firmware version(s) could be included into package control file for preventing of installing packaged modifications onto unsupported firmware.
But OE currently doesn't allow to define additional package metadata in recipes. Patch fixes it.
There is already
RPMSPEC_PREAMBLEvariable used in package_rpm.bbclass. I think, it is still useful for defining custom macros in header of spec file (while additional user-defined metadata is placed somewhere between common tags).I didn't found any way to define newline character inside variable value and it is needed to allow multiple [one-line] metadata fields/tags. So I've used ability of OE to split list-typed variables (and re-joined splitted value with real newline character).
The following changes since commit
cab85fd0b481cdbf36477348de75352be3f38ca2:gdk-pixbuf: Drop unneeded RPROVIDES (2012-05-12 11:23:27 +0100)
up to
052d78ed7f986e76afb1ce6ef02e94ba1bbc9719:package_{ipk, deb, rpm}.bbclass: support additional user-defined metadata (2012-05-13 14:51:26 +0300)
----------------------------------------------------------------
Leonid Borisenko (2):
package.bbclass: add getter of additional metadata package_{ipk, deb, rpm}.bbclass: support additional user-defined metadatameta/classes/package.bbclass | 11 +++++++++++
meta/classes/package_deb.bbclass | 5 +++++ meta/classes/package_ipk.bbclass | 5 +++++ meta/classes/package_rpm.bbclass | 7 +++++++ 4 files changed, 28 insertions(+)
Quoted 3 lines · Leonid Borisenko
Custom metadata field with supported firmware version(s) could be included into package control file for preventing of installing packaged modifications onto unsupported firmware.
Why isn't RDEPENDS sufficient for this?
p.
Quoted 6 lines · Phil Blundell
Quoted 3 lines · Leonid Borisenko
Custom metadata field with supported firmware version(s) could be included into package control file for preventing of installing packaged modifications onto unsupported firmware.
Why isn't RDEPENDS sufficient for this?
I didn't think about using RDEPENDS for specifing supported firmware version.
I'll try to discuss possible scenario with RDEPENDS. Correct me please if I'll miss your point.
So RDEPENDS transforms into Depends field in package control file (I'm speaking about ipk/deb, as it's the chosen format). Depends field contains list of packages (with their's versions) on which target package is depended. Dependencies must be installed before target package and target package will not be installed if all dependencies will not be satisfied.
So there could be empty package kindle-touch-firmware on which target package will depend. Supported version of firmware could be specified as version of package. Package will be empty as only it's version string is signifcant.
Using of stub package for describing supported version of stock proprietary firmware is pretty weird (as for me), but on the other side it's OK as it uses existing capabilities of package format and existing support of package format in OE.
However, user-defined metadata fields are existing capabilities of deb/ipk format too [1].
Also, it could be reasonable to override supported firmware specification and install package forcefully. Noone could foresee whether his/her package will work on future firmware version, but it could in fact work. If package is abandoned and supported firmware version wasn't changed in long time and user want to install it on newer firmware, then using of stub package in Depends field will bring problems. It's not possible to ignore just one package from Depends field, all packages from Depends field will be ignored.
[1] http://www.debian.org/doc/debian-policy/ch-controlfields.html#s5.7
v3 cover Support additional user-defined package metadata
In reply to Leonid BorisenkoPlease, apply patches. They are small, atomic, tested and doesn't ruin anything, just adding the feature.
It is essential feature for us, so we've put efforts into implementing it. We'd like to see it merged into upstream. We are small group of enthusiasts, it will be very hard for us to maintain fork of OE (it will be impossible in fact).
Quoted 46 lines · Leonid Borisenko
I'm an owner of Kindle Touch. It's basically a computer with ARM Cortex-A8 based CPU and Linux. There is a [small] community of enthuasists developing homebrew modifications for stock software. For distributing of these modifications .ipk package format had been chosen with OE as build infrastructure.
There are already several firmware versions for device and some more are expected. Every firmware can introduce unpredictable changes, so modifications for previous firmware versions could stop working.
Custom metadata field with supported firmware version(s) could be included into package control file for preventing of installing packaged modifications onto unsupported firmware.
But OE currently doesn't allow to define additional package metadata in recipes. Patch fixes it.
There is already
RPMSPEC_PREAMBLEvariable used in package_rpm.bbclass. I think, it is still useful for defining custom macros in header of spec file (while additional user-defined metadata is placed somewhere between common tags).I didn't found any way to define newline character inside variable value and it is needed to allow multiple [one-line] metadata fields/tags. So I've used ability of OE to split list-typed variables (and re-joined splitted value with real newline character).
The following changes since commit
cab85fd0b481cdbf36477348de75352be3f38ca2:gdk-pixbuf: Drop unneeded RPROVIDES (2012-05-12 11:23:27 +0100)
up to
052d78ed7f986e76afb1ce6ef02e94ba1bbc9719:package_{ipk, deb, rpm}.bbclass: support additional user-defined metadata (2012-05-13 14:51:26 +0300)
----------------------------------------------------------------
Leonid Borisenko (2):
package.bbclass: add getter of additional metadata package_{ipk, deb, rpm}.bbclass: support additional user-defined metadatameta/classes/package.bbclass | 11 +++++++++++
meta/classes/package_deb.bbclass | 5 +++++ meta/classes/package_ipk.bbclass | 5 +++++ meta/classes/package_rpm.bbclass | 7 +++++++ 4 files changed, 28 insertions(+)
Has it got rejected, applied, forgotten or what?
I think it would make sense to support it. There was just one answer asking if RDEPENDS won't be enough and Ive had good point in my opinion. It's a shame that patch, even after few pings, goes without proper reply...
Quoted 4 lines · Ive Found
Please, apply patches. They are small, atomic, tested and doesn't ruin anything, just adding the feature.
Quoted 52 lines
It is essential feature for us, so we've put efforts into implementing it. We'd like to see it merged into upstream. We are small group of enthusiasts, it will be very hard for us to maintain fork of OE (it will be impossible in fact).
Quoted 46 lines · Leonid Borisenko
I'm an owner of Kindle Touch. It's basically a computer with ARM Cortex-A8 based CPU and Linux. There is a [small] community of enthuasists developing homebrew modifications for stock software. For distributing of these modifications .ipk package format had been chosen with OE as build infrastructure.
There are already several firmware versions for device and some more are expected. Every firmware can introduce unpredictable changes, so modifications for previous firmware versions could stop working.
Custom metadata field with supported firmware version(s) could be included into package control file for preventing of installing packaged modifications onto unsupported firmware.
But OE currently doesn't allow to define additional package metadata in recipes. Patch fixes it.
There is already
RPMSPEC_PREAMBLEvariable used in package_rpm.bbclass. I think, it is still useful for defining custom macros in header of spec file (while additional user-defined metadata is placed somewhere between common tags).I didn't found any way to define newline character inside variable value and it is needed to allow multiple [one-line] metadata fields/tags. So I've used ability of OE to split list-typed variables (and re-joined splitted value with real newline character).
The following changes since commit
cab85fd0b481cdbf36477348de75352be3f38ca2:gdk-pixbuf: Drop unneeded RPROVIDES (2012-05-12 11:23:27 +0100)
up to
052d78ed7f986e76afb1ce6ef02e94ba1bbc9719:package_{ipk, deb, rpm}.bbclass: support additional user-defined metadata (2012-05-13 14:51:26 +0300)
----------------------------------------------------------------
Leonid Borisenko (2):
package.bbclass: add getter of additional metadata package_{ipk, deb, rpm}.bbclass: support additional user-defined metadatameta/classes/package.bbclass | 11 +++++++++++ meta/classes/package_deb.bbclass | 5 +++++ meta/classes/package_ipk.bbclass | 5 +++++ meta/classes/package_rpm.bbclass | 7 +++++++ 4 files changed, 28 insertions(+)
--
Sebastian Krzyszkowiak
dos
Quoted 6 lines · Sebastian Krzyszkowiak
Has it got rejected, applied, forgotten or what?
I think it would make sense to support it. There was just one answer asking if RDEPENDS won't be enough and Ive had good point in my opinion. It's a shame that patch, even after few pings, goes without proper reply...
I think this is the right time to resend this patch rebased against current master so a new review can be done.
Signature · 3 lines
Otavio Salvador O.S. Systems E-mail: [email protected] http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
v2 cover Support additional user-defined metadata
Hi. Here are rebased patches. Thanks for attention!
The following changes since commit b53ea6687b6201c8c5ab5cb0d2a845ef7e7b2abe:
sstate: Bump version number to deal with layout fixes (2012-11-14 23:37:26 +0000)
up to 899ead84c843641a6732621b9b96960d9bef6ecf:
package_{ipk, deb, rpm}.bbclass: support additional user-defined metadata (2012-11-16 20:54:14 +0300)
----------------------------------------------------------------
Leonid Borisenko (2):
package.bbclass: add getter of additional metadata package_{ipk, deb, rpm}.bbclass: support additional user-defined
metadata
meta/classes/package.bbclass | 11 +++++++++++ meta/classes/package_deb.bbclass | 5 +++++ meta/classes/package_ipk.bbclass | 5 +++++ meta/classes/package_rpm.bbclass | 7 +++++++ 4 files changed, 28 insertions(+)
Signature · 1 line
1.7.10.4
PATCH v2 1/2 package.bbclass: add getter of additional metadata
Two variables are searched for value of additional package metadata:
* PACKAGE_ADD_METADATA_<PKGTYPE>
* PACKAGE_ADD_METADATA
First found variable with defined value wins.
<PKGTYPE> is a parameter of getter and expected to be a distinct name of specific package type. For example: 'DEB' or 'RPM'.
Variable can contain multiple [one-line] metadata fields, separated by literal sequence '\n'. Separator can be redefined through variable flag 'separator'. Getter returns found value with separator replaced with newline character.
As side-effect, searched variables acquired flags 'type' (equals to 'list') and 'separator'.
--- meta/classes/package.bbclass | 11 +++++++++++ 1 file changed, 11 insertions(+)
meta/classes/package.bbclass +11 -0
@@ -372,6 +372,17 @@ def get_package_mapping (pkg, d): return pkg +def get_package_additional_metadata (pkg_type, d): + base_key = "PACKAGE_ADD_METADATA" + for key in ("%s_%s" % (base_key, pkg_type.upper()), base_key): + if d.getVar(key) is None: + continue + d.setVarFlag(key, "type", "list") + if d.getVarFlag(key, "separator") is None: + d.setVarFlag(key, "separator", "\\n") + metadata_fields = [field.strip() for field in oe.data.typed_value(key, d)] + return "\n".join(metadata_fields).strip() + def runtime_mapping_rename (varname, d): #bb.note("%s before: %s" % (varname, d.getVar(varname, True)))
Signature · 1 line
1.7.10.4
PATCH v2 2/2 package_{ipk, deb, rpm}.bbclass: support additional user-defined metadata
In reply to Leonid BorisenkoAdditional metadata from user-defined variable is written into control/spec file of binary package.
Three variables are searched for adiitional package metadata:
* PACKAGE_ADD_METADATA_<PKGTYPE>_<PN>
* PACKAGE_ADD_METADATA_<PKGTYPE>
* PACKAGE_ADD_METADATA
First found variable with defined value wins.
<PN> is a package name. <PKGTYPE> is a distinct name of specific package type:
* IPK for .ipk packages
* DEB for .deb packages
* RPM for .rpm packages
Variable can contain multiple [one-line] metadata fields separated by literal sequence '\n'. Separator can be redefined through variable flag 'separator'. In package control/spec file separator is replaced by newline character.
--- meta/classes/package_deb.bbclass | 5 +++++ meta/classes/package_ipk.bbclass | 5 +++++ meta/classes/package_rpm.bbclass | 7 +++++++ 3 files changed, 17 insertions(+)
meta/classes/package_deb.bbclass +5 -0
@@ -332,6 +332,11 @@ python do_package_deb () { raise bb.build.FuncFailed("Missing field for deb generation: %s" % value) # more fields + custom_fields_chunk = get_package_additional_metadata("deb", localdata) + if custom_fields_chunk is not None: + ctrlfile.write(unicode(custom_fields_chunk)) + ctrlfile.write("\n") + mapping_rename_hook(localdata) def debian_cmp_remap(var):
meta/classes/package_ipk.bbclass +5 -0
@@ -370,6 +370,11 @@ python do_package_ipk () { raise bb.build.FuncFailed("Missing field for ipk generation: %s" % value) # more fields + custom_fields_chunk = get_package_additional_metadata("ipk", localdata) + if custom_fields_chunk is not None: + ctrlfile.write(custom_fields_chunk) + ctrlfile.write("\n") + mapping_rename_hook(localdata) def debian_cmp_remap(var):
meta/classes/package_rpm.bbclass +7 -0
@@ -720,6 +720,7 @@ python write_specfile () { srcmaintainer = d.getVar('MAINTAINER', True) srchomepage = d.getVar('HOMEPAGE', True) srcdescription = d.getVar('DESCRIPTION', True) or "." + srccustomtagschunk = get_package_additional_metadata("rpm", d) srcdepends = strip_multilib_deps(d.getVar('DEPENDS', True), d) srcrdepends = []
@@ -773,6 +774,7 @@ python write_specfile () { splitlicense = (localdata.getVar('LICENSE', True) or "") splitsection = (localdata.getVar('SECTION', True) or "") splitdescription = (localdata.getVar('DESCRIPTION', True) or ".") + splitcustomtagschunk = get_package_additional_metadata("rpm", localdata) translate_vers('RDEPENDS', localdata) translate_vers('RRECOMMENDS', localdata)
@@ -837,6 +839,9 @@ python write_specfile () { spec_preamble_bottom.append('License: %s' % splitlicense) spec_preamble_bottom.append('Group: %s' % splitsection) + if srccustomtagschunk != splitcustomtagschunk: + spec_preamble_bottom.append(splitcustomtagschunk) + # Replaces == Obsoletes && Provides robsoletes = bb.utils.explode_dep_versions2(splitrobsoletes or "") rprovides = bb.utils.explode_dep_versions2(splitrprovides or "")
@@ -927,6 +932,8 @@ python write_specfile () { spec_preamble_top.append('Group: %s' % srcsection) spec_preamble_top.append('Packager: %s' % srcmaintainer) spec_preamble_top.append('URL: %s' % srchomepage) + if srccustomtagschunk: + spec_preamble_top.append(srccustomtagschunk) tail_source(d) # Replaces == Obsoletes && Provides
Signature · 1 line
1.7.10.4
PATCH v2 1/1 Support additional user-defined metadata
In reply to Leonid BorisenkoHi. Any comments?