* Re: [PATCH] Add support for supplying more types of debian package relationships
2019-09-11 8:57 ` Jan Kiszka
@ 2019-09-11 9:02 ` Jan Kiszka
2019-09-11 9:32 ` Dalamagkidis, Konstantinos
` (2 subsequent siblings)
3 siblings, 0 replies; 11+ messages in thread
From: Jan Kiszka @ 2019-09-11 9:02 UTC (permalink / raw)
To: [ext] Dalamagkidis, Konstantinos, isar-users, Henning Schild
On 11.09.19 10:57, Jan Kiszka wrote:
> On 11.09.19 10:41, [ext] Dalamagkidis, Konstantinos wrote:
>> We need to be able to specify other package relationships, such as
>> Pre-Depends or Provides/Replaces/Conflicts.
>>
>> This change supports supplying DEBIAN_PREDEPENDS, DEBIAN_REPLACES,
>> DEBIAN_CONFLICTS and DEBIAN_PROVIDES, as well as bitbake-style RDEPENDS
>> or RDEPENDS_{PN} variables. The DEBIAN_* take priority.
>>
>> Signed-off-by: Konstantinos Dalamagkidis <konstantinos.dalamagkidis@siemens.com>
>> ---
>> meta/classes/debianize.bbclass | 19 +++++++++++++++++++
>> meta/classes/dpkg-raw.bbclass | 1 -
>> 2 files changed, 19 insertions(+), 1 deletion(-)
>>
>> diff --git a/meta/classes/debianize.bbclass b/meta/classes/debianize.bbclass
>> index ad3a98e..26002c5 100644
>> --- a/meta/classes/debianize.bbclass
>> +++ b/meta/classes/debianize.bbclass
>> @@ -5,6 +5,21 @@
>> CHANGELOG_V ?= "${PV}"
>> +DEBIAN_DEPENDS ??= "${@deb_get_relationship(d, 'RDEPENDS')}"
>> +DEBIAN_PREDEPENDS ??= "${@deb_get_relationship(d, 'RPREDEPENDS')}"
>> +DEBIAN_CONFLICTS ??= "${@deb_get_relationship(d, 'RCONFLICTS')}"
>> +DEBIAN_REPLACES ??= "${@deb_get_relationship(d, 'RREPLACES')}"
>> +DEBIAN_PROVIDES ??= "${@deb_get_relationship(d, 'RPROVIDES')}"
>> +
>> +def deb_get_relationship(d, relationship):
>> + rel = d.getVar(relationship + '_' + d.getVar('PN', True), True)
>> + if rel:
>> + return rel
>> + rel = d.getVar(relationship, True)
>> + if rel:
>> + return rel
>> + return ""
>> +
>> deb_add_changelog() {
>> timestamp=$(find ${S}/ -type f -not -path "${S}/debian/*" -printf
>> "%T@\n"|sort -n -r|head -n 1)
>> if [ -n "${timestamp}" ]; then
>> @@ -42,6 +57,10 @@ Build-Depends: debhelper (>= ${compat})
>> Package: ${PN}
>> Architecture: any
>> Depends: ${DEBIAN_DEPENDS}
>> +Pre-Depends: ${DEBIAN_PREDEPENDS}
>> +Replaces: ${DEBIAN_REPLACES}
>> +Conflicts: ${DEBIAN_CONFLICTS}
>> +Provides: ${DEBIAN_PROVIDES}
>> Description: ${DESCRIPTION}
>> EOF
>> }
>> diff --git a/meta/classes/dpkg-raw.bbclass b/meta/classes/dpkg-raw.bbclass
>> index ea03ea4..0c484fc 100644
>> --- a/meta/classes/dpkg-raw.bbclass
>> +++ b/meta/classes/dpkg-raw.bbclass
>> @@ -5,7 +5,6 @@
>> inherit dpkg
>> -DEBIAN_DEPENDS ?= ""
>> MAINTAINER ?= "Unknown maintainer <unknown@example.com>"
>> D = "${S}"
>>
>
> This, as well as your DPKG_ARCH patch, is enhancing and further establishing
> debianize.bbclase as an official interface. I already urged Henning to do that -
> which includes writing documentation for this. Your change here should extend
> that (not yet existing) documentation as well.
>
And, of course, we need some basic test cases as well.
Jan
> One of the thing to consider while designing & enhancing the recipe API for
> debianize: We should not create something that is as complex as writing Debian
> control files directly - or even more complex than that.
>
> BTW, what kind of application packages are you generating for dpkg-raw?
>
> Jan
>
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 11+ messages in thread* RE: [PATCH] Add support for supplying more types of debian package relationships
2019-09-11 8:57 ` Jan Kiszka
2019-09-11 9:02 ` Jan Kiszka
@ 2019-09-11 9:32 ` Dalamagkidis, Konstantinos
2019-10-14 17:01 ` Henning Schild
2019-09-13 8:32 ` Baurzhan Ismagulov
2019-10-14 16:49 ` Henning Schild
3 siblings, 1 reply; 11+ messages in thread
From: Dalamagkidis, Konstantinos @ 2019-09-11 9:32 UTC (permalink / raw)
To: jan.kiszka, isar-users, henning.schild
> On 11.09.19 10:41, [ext] Dalamagkidis, Konstantinos wrote:
> > We need to be able to specify other package relationships, such as
> > Pre-Depends or Provides/Replaces/Conflicts.
> >
> > This change supports supplying DEBIAN_PREDEPENDS, DEBIAN_REPLACES,
> > DEBIAN_CONFLICTS and DEBIAN_PROVIDES, as well as bitbake-style
> > RDEPENDS or RDEPENDS_{PN} variables. The DEBIAN_* take priority.
> >
>
> This, as well as your DPKG_ARCH patch, is enhancing and further establishing
> debianize.bbclase as an official interface. I already urged Henning to do that -
> which includes writing documentation for this. Your change here should extend that
> (not yet existing) documentation as well.
>
> One of the thing to consider while designing & enhancing the recipe API for
> debianize: We should not create something that is as complex as writing Debian
> control files directly - or even more complex than that.
>
> BTW, what kind of application packages are you generating for dpkg-raw?
We have ca 20 packages that use dpkg-raw, split more or less
equally between configuration, scripts and some pre-built
binaries. The conflicts/replaces is used in a couple of
configuration packages. We are also porting recipes from a
previous version that was using "plain yocto", so it is easier if
we can just use RDEPENDS, RPROVIDES, etc. Personally I would
prefer to use dpkg over dpkg-raw everywhere, but other colleagues
find dpkg-raw easier.
Rgds
Konstantinos
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [PATCH] Add support for supplying more types of debian package relationships
2019-09-11 9:32 ` Dalamagkidis, Konstantinos
@ 2019-10-14 17:01 ` Henning Schild
2019-10-15 10:38 ` Baurzhan Ismagulov
0 siblings, 1 reply; 11+ messages in thread
From: Henning Schild @ 2019-10-14 17:01 UTC (permalink / raw)
To: Dalamagkidis, Konstantinos (MO RS EN CCIT TEC AR)
Cc: Kiszka, Jan (CT RDA IOT SES-DE), isar-users
Am Wed, 11 Sep 2019 11:32:08 +0200
schrieb "Dalamagkidis, Konstantinos (MO RS EN CCIT TEC AR)"
<konstantinos.dalamagkidis@siemens.com>:
> > On 11.09.19 10:41, [ext] Dalamagkidis, Konstantinos wrote:
> > > We need to be able to specify other package relationships, such as
> > > Pre-Depends or Provides/Replaces/Conflicts.
> > >
> > > This change supports supplying DEBIAN_PREDEPENDS, DEBIAN_REPLACES,
> > > DEBIAN_CONFLICTS and DEBIAN_PROVIDES, as well as bitbake-style
> > > RDEPENDS or RDEPENDS_{PN} variables. The DEBIAN_* take priority.
> > >
> >
> > This, as well as your DPKG_ARCH patch, is enhancing and further
> > establishing debianize.bbclase as an official interface. I already
> > urged Henning to do that - which includes writing documentation for
> > this. Your change here should extend that (not yet existing)
> > documentation as well.
> >
> > One of the thing to consider while designing & enhancing the recipe
> > API for debianize: We should not create something that is as
> > complex as writing Debian control files directly - or even more
> > complex than that.
> >
> > BTW, what kind of application packages are you generating for
> > dpkg-raw?
>
> We have ca 20 packages that use dpkg-raw, split more or less
> equally between configuration, scripts and some pre-built
> binaries. The conflicts/replaces is used in a couple of
> configuration packages. We are also porting recipes from a
> previous version that was using "plain yocto", so it is easier if
> we can just use RDEPENDS, RPROVIDES, etc. Personally I would
> prefer to use dpkg over dpkg-raw everywhere, but other colleagues
> find dpkg-raw easier.
My suggestion here is to keep that patch in your layer. You having that
problem 20 times does not make it common, 20 independent users would ;).
So you could put that magic into a dpkg-my-layer-yocto-glue class. The
deps in Isar are a pain, because we are dealing with two worlds. I
personally do not think that "pretending this away" is a good idea.
If you actually have configure + compile tasks in your dpkg-raw you are
on the wrong track and should stop pretending its yocto! Or at least
make sure all that gets done in buildchroot. If you want please explain
what you are doing, like Jan asked before.
Henning
> Rgds
> Konstantinos
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [PATCH] Add support for supplying more types of debian package relationships
2019-10-14 17:01 ` Henning Schild
@ 2019-10-15 10:38 ` Baurzhan Ismagulov
0 siblings, 0 replies; 11+ messages in thread
From: Baurzhan Ismagulov @ 2019-10-15 10:38 UTC (permalink / raw)
To: isar-users
On Mon, Oct 14, 2019 at 07:01:00PM +0200, Henning Schild wrote:
> My suggestion here is to keep that patch in your layer. You having that
> problem 20 times does not make it common, 20 independent users would ;).
>
> So you could put that magic into a dpkg-my-layer-yocto-glue class. The
> deps in Isar are a pain, because we are dealing with two worlds. I
> personally do not think that "pretending this away" is a good idea.
>
> If you actually have configure + compile tasks in your dpkg-raw you are
> on the wrong track and should stop pretending its yocto! Or at least
> make sure all that gets done in buildchroot. If you want please explain
> what you are doing, like Jan asked before.
People use this feature and ask for various corner cases. If we can cover those
till proper dependency support is implemented (which would probably require
modifying bitbake or developing a different tool), I'd like to apply the patch
because it helps users today.
Konstantinos, do you see a possibility to document this and provide a test
case?
With kind regards,
Baurzhan.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] Add support for supplying more types of debian package relationships
2019-09-11 8:57 ` Jan Kiszka
2019-09-11 9:02 ` Jan Kiszka
2019-09-11 9:32 ` Dalamagkidis, Konstantinos
@ 2019-09-13 8:32 ` Baurzhan Ismagulov
2019-10-14 16:49 ` Henning Schild
3 siblings, 0 replies; 11+ messages in thread
From: Baurzhan Ismagulov @ 2019-09-13 8:32 UTC (permalink / raw)
To: isar-users
On Wed, Sep 11, 2019 at 10:57:34AM +0200, Jan Kiszka wrote:
> One of the thing to consider while designing & enhancing the recipe API for
> debianize: We should not create something that is as complex as writing
> Debian control files directly - or even more complex than that.
This is exactly the point. In my experience, new users tend to shy away from
debianizing their applications, presumably because debhelper documentation is
somewhat complicated -- at least I spent more time with the docs than with
actual debianizing. So, people are tempted to use quick solutions, and my
impression is that debianize.bbclass is a good helper here. It will get
complicated as we cover more use cases, and using tons of variables to control
the configuration is as simple as we can get it. We should gather experience
with that, but I think it will still have its value as first debianizing aid.
After one is past that step, we should recommend moving the debian control
files from meta to the application in the manual.
With kind regards,
Baurzhan.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] Add support for supplying more types of debian package relationships
2019-09-11 8:57 ` Jan Kiszka
` (2 preceding siblings ...)
2019-09-13 8:32 ` Baurzhan Ismagulov
@ 2019-10-14 16:49 ` Henning Schild
3 siblings, 0 replies; 11+ messages in thread
From: Henning Schild @ 2019-10-14 16:49 UTC (permalink / raw)
To: Jan Kiszka; +Cc: [ext] Dalamagkidis, Konstantinos, isar-users
Am Wed, 11 Sep 2019 10:57:34 +0200
schrieb Jan Kiszka <jan.kiszka@siemens.com>:
> On 11.09.19 10:41, [ext] Dalamagkidis, Konstantinos wrote:
> > We need to be able to specify other package relationships, such as
> > Pre-Depends or Provides/Replaces/Conflicts.
> >
> > This change supports supplying DEBIAN_PREDEPENDS, DEBIAN_REPLACES,
> > DEBIAN_CONFLICTS and DEBIAN_PROVIDES, as well as bitbake-style
> > RDEPENDS or RDEPENDS_{PN} variables. The DEBIAN_* take priority.
> >
> > Signed-off-by: Konstantinos Dalamagkidis
> > <konstantinos.dalamagkidis@siemens.com> ---
> > meta/classes/debianize.bbclass | 19 +++++++++++++++++++
> > meta/classes/dpkg-raw.bbclass | 1 -
> > 2 files changed, 19 insertions(+), 1 deletion(-)
> >
> > diff --git a/meta/classes/debianize.bbclass
> > b/meta/classes/debianize.bbclass index ad3a98e..26002c5 100644
> > --- a/meta/classes/debianize.bbclass
> > +++ b/meta/classes/debianize.bbclass
> > @@ -5,6 +5,21 @@
> >
> > CHANGELOG_V ?= "${PV}"
> >
> > +DEBIAN_DEPENDS ??= "${@deb_get_relationship(d, 'RDEPENDS')}"
> > +DEBIAN_PREDEPENDS ??= "${@deb_get_relationship(d, 'RPREDEPENDS')}"
> > +DEBIAN_CONFLICTS ??= "${@deb_get_relationship(d, 'RCONFLICTS')}"
> > +DEBIAN_REPLACES ??= "${@deb_get_relationship(d, 'RREPLACES')}"
> > +DEBIAN_PROVIDES ??= "${@deb_get_relationship(d, 'RPROVIDES')}"
> > +
> > +def deb_get_relationship(d, relationship):
> > + rel = d.getVar(relationship + '_' + d.getVar('PN', True), True)
> > + if rel:
> > + return rel
> > + rel = d.getVar(relationship, True)
> > + if rel:
> > + return rel
> > + return ""
> > +
> > deb_add_changelog() {
> > timestamp=$(find ${S}/ -type f -not -path "${S}/debian/*"
> > -printf "%T@\n"|sort -n -r|head -n 1) if [ -n "${timestamp}" ]; then
> > @@ -42,6 +57,10 @@ Build-Depends: debhelper (>= ${compat})
> > Package: ${PN}
> > Architecture: any
> > Depends: ${DEBIAN_DEPENDS}
> > +Pre-Depends: ${DEBIAN_PREDEPENDS}
> > +Replaces: ${DEBIAN_REPLACES}
> > +Conflicts: ${DEBIAN_CONFLICTS}
> > +Provides: ${DEBIAN_PROVIDES}
> > Description: ${DESCRIPTION}
> > EOF
> > }
> > diff --git a/meta/classes/dpkg-raw.bbclass
> > b/meta/classes/dpkg-raw.bbclass index ea03ea4..0c484fc 100644
> > --- a/meta/classes/dpkg-raw.bbclass
> > +++ b/meta/classes/dpkg-raw.bbclass
> > @@ -5,7 +5,6 @@
> >
> > inherit dpkg
> >
> > -DEBIAN_DEPENDS ?= ""
> > MAINTAINER ?= "Unknown maintainer <unknown@example.com>"
> >
> > D = "${S}"
> >
>
> This, as well as your DPKG_ARCH patch, is enhancing and further
> establishing debianize.bbclase as an official interface. I already
> urged Henning to do that - which includes writing documentation for
> this. Your change here should extend that (not yet existing)
> documentation as well.
I introduced it as a hidden feature because dpkg-raw needed it to go
dpkg-buildpackage as well. At that time i knew it would be very useful
outside of this context, and i bet the commit messages or discussions
around it included that "insight".
If we have reached the point where this becomes "official" i would be
happy to write a few lines of documentation on it. But really everyone
could do that if me not writing that blocks anyone.
I know quite a few people that are using it and did not find major
issues so it could be safe to assume it is good enough to begin with.
Henning
> One of the thing to consider while designing & enhancing the recipe
> API for debianize: We should not create something that is as complex
> as writing Debian control files directly - or even more complex than
> that.
>
> BTW, what kind of application packages are you generating for
> dpkg-raw?
>
> Jan
>
^ permalink raw reply [flat|nested] 11+ messages in thread