[RFC PATCH 0/1] Special debian depends entries

[RFC PATCH 0/1] Special debian depends entries

[claudius.heine.ext]

From: Claudius Heine <ch@denx.de>

Hi,

this patch is to start the discussion about how to implement the debian
depends.

Instead of going the just 'echo ${DEBIAN_DEPENDS}' route, I chose to be
backwards compatible. Another reason for this is also for the possible
next feature where ISAR 'DEPENDS' or 'RDEPENDS' will be converted to the
package specific 'DEBIAN_DEPENDS'.

A short discussion with Henning, discovered that there might be more
dissussion needed for this feature.

Cheers,
Claudius

Claudius Heine (1):
  meta/dpkg-raw: support for special debian package dependencies

 meta/classes/dpkg-raw.bbclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

-- 
2.15.1

[RFC PATCH 1/1] meta/dpkg-raw: support for special debian package dependencies

[claudius.heine.ext]

From: Claudius Heine <ch@denx.de>

Now special debian dependencies can be specified in the recipe like
this:

    DEBIAN_DEPENDS = "'libc (>= 2.16)' 'tar | bsdtar' systemd"

and the package contains this 'Depends' entry:

    Depends: libc (>= 2.16), tar | bsdtar, systemd

Signed-off-by: Claudius Heine <ch@denx.de>
---
 meta/classes/dpkg-raw.bbclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/classes/dpkg-raw.bbclass b/meta/classes/dpkg-raw.bbclass
index 1435e10..42a33e0 100644
--- a/meta/classes/dpkg-raw.bbclass
+++ b/meta/classes/dpkg-raw.bbclass
@@ -31,9 +31,9 @@ do_deb_package_prepare() {
 	__EOF__
 	if [ ${DEBIAN_DEPENDS} != "" ]
 	then
+		DEBIAN_DEPS="$(for i in ${DEBIAN_DEPENDS};do echo $i,;done|tr '\n' ' '|sed 's/, *$//')"
 		echo -n Depends: >> ${D}/DEBIAN/control
-		echo ${DEBIAN_DEPENDS} | tr '[:blank:]' ',' >> \
-			${D}/DEBIAN/control
+		echo " ${DEBIAN_DEPS}" >> ${D}/DEBIAN/control
 	fi
 	for t in pre post
 	do
-- 
2.15.1

Re: [RFC PATCH 0/1] Special debian depends entries

[Henning Schild]

Am Wed, 13 Dec 2017 17:07:09 +0100
schrieb "[ext] claudius.heine.ext@siemens.com"
<claudius.heine.ext@siemens.com>:

> From: Claudius Heine <ch@denx.de>
> 
> Hi,
> 
> this patch is to start the discussion about how to implement the
> debian depends.
> 
> Instead of going the just 'echo ${DEBIAN_DEPENDS}' route, I chose to
> be backwards compatible. Another reason for this is also for the
> possible next feature where ISAR 'DEPENDS' or 'RDEPENDS' will be
> converted to the package specific 'DEBIAN_DEPENDS'.

With the current nature of dpkg-raw DEPENDS and RDEPENDS make no sense.
Maybe some day the class will do more than just wrap stuff in a
package, but at the moment i do not see that coming.
And even if that ever happened the class could take care of turning the
bitbake-list (R)DEPENDS into a Debian comma-seperated list.

I tried your code in a bash (not in Isar/bitbake etc.) and i got a few
more commas that i would have expected.

'libc, (>=, 2.16)', 'tar, |, bsdtar', systemd

Shell code is nasty, i think i do not even want to know why it worked
for you or wether it would work in Isar with my build env.

I think i still prefer just taking the string from the recipe, not
messing with it at all.

Henning

> A short discussion with Henning, discovered that there might be more
> dissussion needed for this feature.
> 
> Cheers,
> Claudius
> 
> Claudius Heine (1):
>   meta/dpkg-raw: support for special debian package dependencies
> 
>  meta/classes/dpkg-raw.bbclass | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 

Re: [RFC PATCH 0/1] Special debian depends entries

[Claudius Heine]

[-- Attachment #1: Type: text/plain, Size: 2359 bytes --]

Hi Henning,

On Thu, 2017-12-14 at 14:42 +0100, Henning Schild wrote:
> Am Wed, 13 Dec 2017 17:07:09 +0100
> schrieb "[ext] claudius.heine.ext@siemens.com"
> <claudius.heine.ext@siemens.com>:
> 
> > From: Claudius Heine <ch@denx.de>
> > 
> > Hi,
> > 
> > this patch is to start the discussion about how to implement the
> > debian depends.
> > 
> > Instead of going the just 'echo ${DEBIAN_DEPENDS}' route, I chose
> > to
> > be backwards compatible. Another reason for this is also for the
> > possible next feature where ISAR 'DEPENDS' or 'RDEPENDS' will be
> > converted to the package specific 'DEBIAN_DEPENDS'.
> 
> With the current nature of dpkg-raw DEPENDS and RDEPENDS make no
> sense.
> Maybe some day the class will do more than just wrap stuff in a
> package, but at the moment i do not see that coming.
> And even if that ever happened the class could take care of turning
> the
> bitbake-list (R)DEPENDS into a Debian comma-seperated list.
> 
> I tried your code in a bash (not in Isar/bitbake etc.) and i got a
> few
> more commas that i would have expected.
> 
> 'libc, (>=, 2.16)', 'tar, |, bsdtar', systemd
> 
> Shell code is nasty, i think i do not even want to know why it worked
> for you or wether it would work in Isar with my build env.

I works in here because the ${DEBIAN_DEPENDS} is inserted by bitbake
before any shell is executed. So in shell code for this example looks
like this:

    DEBIAN_DEPS="$(for i in 'libc (>= 2.16)' 'tar | bsdtar' systemd;do
echo $i,;done|tr '\n' ' '|sed 's/, *$//')"

If you try that out with your shell:

    $ echo "$(for i in 'libc (>= 2.16)' 'tar | bsdtar' systemd;do echo
$i,;done|tr '\n' ' '|sed 's/, *$//')"
    libc (>= 2.16), tar | bsdtar, systemd

It works correctly just like in bitbake.

DEBIAN_DEPENDS is not a shell variable but a bitbake one.

But I get your point that this is confusing and error-prone. Doing it
with python might be easier.

Cheers,
Claudius

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de

            PGP key: 6FF2 E59F 00C6 BC28 31D8 64C1 1173 CB19 9808 B153
                              Keyserver: hkp://pool.sks-keyservers.net

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [RFC PATCH 0/1] Special debian depends entries

[Henning Schild]

Am Thu, 14 Dec 2017 15:12:37 +0100
schrieb Claudius Heine <ch@denx.de>:

> Hi Henning,
> 
> On Thu, 2017-12-14 at 14:42 +0100, Henning Schild wrote:
> > Am Wed, 13 Dec 2017 17:07:09 +0100
> > schrieb "[ext] claudius.heine.ext@siemens.com"
> > <claudius.heine.ext@siemens.com>:
> >   
> > > From: Claudius Heine <ch@denx.de>
> > > 
> > > Hi,
> > > 
> > > this patch is to start the discussion about how to implement the
> > > debian depends.
> > > 
> > > Instead of going the just 'echo ${DEBIAN_DEPENDS}' route, I chose
> > > to
> > > be backwards compatible. Another reason for this is also for the
> > > possible next feature where ISAR 'DEPENDS' or 'RDEPENDS' will be
> > > converted to the package specific 'DEBIAN_DEPENDS'.  
> > 
> > With the current nature of dpkg-raw DEPENDS and RDEPENDS make no
> > sense.
> > Maybe some day the class will do more than just wrap stuff in a
> > package, but at the moment i do not see that coming.
> > And even if that ever happened the class could take care of turning
> > the
> > bitbake-list (R)DEPENDS into a Debian comma-seperated list.
> > 
> > I tried your code in a bash (not in Isar/bitbake etc.) and i got a
> > few
> > more commas that i would have expected.
> > 
> > 'libc, (>=, 2.16)', 'tar, |, bsdtar', systemd
> > 
> > Shell code is nasty, i think i do not even want to know why it
> > worked for you or wether it would work in Isar with my build env.  
> 
> I works in here because the ${DEBIAN_DEPENDS} is inserted by bitbake
> before any shell is executed. So in shell code for this example looks
> like this:
> 
>     DEBIAN_DEPS="$(for i in 'libc (>= 2.16)' 'tar | bsdtar' systemd;do
> echo $i,;done|tr '\n' ' '|sed 's/, *$//')"
> 
> If you try that out with your shell:
> 
>     $ echo "$(for i in 'libc (>= 2.16)' 'tar | bsdtar' systemd;do echo
> $i,;done|tr '\n' ' '|sed 's/, *$//')"
>     libc (>= 2.16), tar | bsdtar, systemd
> 
> It works correctly just like in bitbake.
> 
> DEBIAN_DEPENDS is not a shell variable but a bitbake one.
> 
> But I get your point that this is confusing and error-prone. Doing it
> with python might be easier.

It is just one of multiple points.

Could you live with the simple solution of just taking the string from
the recipe and requiring recipe-updates?

Henning

> Cheers,
> Claudius
> 

Re: [RFC PATCH 0/1] Special debian depends entries

[Claudius Heine]

[-- Attachment #1: Type: text/plain, Size: 3453 bytes --]

On Thu, 2017-12-14 at 15:36 +0100, Henning Schild wrote:
> Am Thu, 14 Dec 2017 15:12:37 +0100
> schrieb Claudius Heine <ch@denx.de>:
> 
> > Hi Henning,
> > 
> > On Thu, 2017-12-14 at 14:42 +0100, Henning Schild wrote:
> > > Am Wed, 13 Dec 2017 17:07:09 +0100
> > > schrieb "[ext] claudius.heine.ext@siemens.com"
> > > <claudius.heine.ext@siemens.com>:
> > >   
> > > > From: Claudius Heine <ch@denx.de>
> > > > 
> > > > Hi,
> > > > 
> > > > this patch is to start the discussion about how to implement
> > > > the
> > > > debian depends.
> > > > 
> > > > Instead of going the just 'echo ${DEBIAN_DEPENDS}' route, I
> > > > chose
> > > > to
> > > > be backwards compatible. Another reason for this is also for
> > > > the
> > > > possible next feature where ISAR 'DEPENDS' or 'RDEPENDS' will
> > > > be
> > > > converted to the package specific 'DEBIAN_DEPENDS'.  
> > > 
> > > With the current nature of dpkg-raw DEPENDS and RDEPENDS make no
> > > sense.
> > > Maybe some day the class will do more than just wrap stuff in a
> > > package, but at the moment i do not see that coming.
> > > And even if that ever happened the class could take care of
> > > turning
> > > the
> > > bitbake-list (R)DEPENDS into a Debian comma-seperated list.
> > > 
> > > I tried your code in a bash (not in Isar/bitbake etc.) and i got
> > > a
> > > few
> > > more commas that i would have expected.
> > > 
> > > 'libc, (>=, 2.16)', 'tar, |, bsdtar', systemd
> > > 
> > > Shell code is nasty, i think i do not even want to know why it
> > > worked for you or wether it would work in Isar with my build
> > > env.  
> > 
> > I works in here because the ${DEBIAN_DEPENDS} is inserted by
> > bitbake
> > before any shell is executed. So in shell code for this example
> > looks
> > like this:
> > 
> >     DEBIAN_DEPS="$(for i in 'libc (>= 2.16)' 'tar | bsdtar'
> > systemd;do
> > echo $i,;done|tr '\n' ' '|sed 's/, *$//')"
> > 
> > If you try that out with your shell:
> > 
> >     $ echo "$(for i in 'libc (>= 2.16)' 'tar | bsdtar' systemd;do
> > echo
> > $i,;done|tr '\n' ' '|sed 's/, *$//')"
> >     libc (>= 2.16), tar | bsdtar, systemd
> > 
> > It works correctly just like in bitbake.
> > 
> > DEBIAN_DEPENDS is not a shell variable but a bitbake one.
> > 
> > But I get your point that this is confusing and error-prone. Doing
> > it
> > with python might be easier.
> 
> It is just one of multiple points.
> 
> Could you live with the simple solution of just taking the string
> from
> the recipe and requiring recipe-updates?

I would rather not break backward compatibility.

I know that isar is not at a stage were a fancy idea like this one
really matters, but for me this issue is currently not important enough
to justify this breakage and the work to change all the recipes relying
on the old behavior.
So for me we either fix it in a compatible way, like my patch does, or
don't bother and wait for a usecase where we cannot advice the user to
just debianize the sources in some way.

Cheers,
Claudius

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de

            PGP key: 6FF2 E59F 00C6 BC28 31D8 64C1 1173 CB19 9808 B153
                              Keyserver: hkp://pool.sks-keyservers.net

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [RFC PATCH 0/1] Special debian depends entries

[Henning Schild]

Am Thu, 14 Dec 2017 15:52:18 +0100
schrieb Claudius Heine <ch@denx.de>:

> On Thu, 2017-12-14 at 15:36 +0100, Henning Schild wrote:
> > Am Thu, 14 Dec 2017 15:12:37 +0100
> > schrieb Claudius Heine <ch@denx.de>:
> >   
> > > Hi Henning,
> > > 
> > > On Thu, 2017-12-14 at 14:42 +0100, Henning Schild wrote:  
> > > > Am Wed, 13 Dec 2017 17:07:09 +0100
> > > > schrieb "[ext] claudius.heine.ext@siemens.com"
> > > > <claudius.heine.ext@siemens.com>:
> > > >     
> > > > > From: Claudius Heine <ch@denx.de>
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > this patch is to start the discussion about how to implement
> > > > > the
> > > > > debian depends.
> > > > > 
> > > > > Instead of going the just 'echo ${DEBIAN_DEPENDS}' route, I
> > > > > chose
> > > > > to
> > > > > be backwards compatible. Another reason for this is also for
> > > > > the
> > > > > possible next feature where ISAR 'DEPENDS' or 'RDEPENDS' will
> > > > > be
> > > > > converted to the package specific 'DEBIAN_DEPENDS'.    
> > > > 
> > > > With the current nature of dpkg-raw DEPENDS and RDEPENDS make no
> > > > sense.
> > > > Maybe some day the class will do more than just wrap stuff in a
> > > > package, but at the moment i do not see that coming.
> > > > And even if that ever happened the class could take care of
> > > > turning
> > > > the
> > > > bitbake-list (R)DEPENDS into a Debian comma-seperated list.
> > > > 
> > > > I tried your code in a bash (not in Isar/bitbake etc.) and i got
> > > > a
> > > > few
> > > > more commas that i would have expected.
> > > > 
> > > > 'libc, (>=, 2.16)', 'tar, |, bsdtar', systemd
> > > > 
> > > > Shell code is nasty, i think i do not even want to know why it
> > > > worked for you or wether it would work in Isar with my build
> > > > env.    
> > > 
> > > I works in here because the ${DEBIAN_DEPENDS} is inserted by
> > > bitbake
> > > before any shell is executed. So in shell code for this example
> > > looks
> > > like this:
> > > 
> > >     DEBIAN_DEPS="$(for i in 'libc (>= 2.16)' 'tar | bsdtar'
> > > systemd;do
> > > echo $i,;done|tr '\n' ' '|sed 's/, *$//')"
> > > 
> > > If you try that out with your shell:
> > > 
> > >     $ echo "$(for i in 'libc (>= 2.16)' 'tar | bsdtar' systemd;do
> > > echo
> > > $i,;done|tr '\n' ' '|sed 's/, *$//')"
> > >     libc (>= 2.16), tar | bsdtar, systemd
> > > 
> > > It works correctly just like in bitbake.
> > > 
> > > DEBIAN_DEPENDS is not a shell variable but a bitbake one.
> > > 
> > > But I get your point that this is confusing and error-prone. Doing
> > > it
> > > with python might be easier.  
> > 
> > It is just one of multiple points.
> > 
> > Could you live with the simple solution of just taking the string
> > from
> > the recipe and requiring recipe-updates?  
> 
> I would rather not break backward compatibility.
> 
> I know that isar is not at a stage were a fancy idea like this one
> really matters, but for me this issue is currently not important
> enough to justify this breakage and the work to change all the
> recipes relying on the old behavior.

How many recipes are we talking about here 3-5 in your layer? Let us
please not make this about principle but just be pragmatic about it.
The change to the recipes is trivial! I will come over to your desk and
help you with it, but only if you are doing the 15+ on my side ;).

Christian said he wants to be able to express versions and choices and
does not care about compatibility. And so far i did not hear any other
complaints.

To me it is the perfect time to take the issue seriously. Because now
we can still change the interface without making too many people angry.

> So for me we either fix it in a compatible way, like my patch does, or
> don't bother and wait for a usecase where we cannot advice the user to
> just debianize the sources in some way.

No, Christian identified a bug that should be fixed.

You can always debianize sources, you could probably do everything that
dpkg-raw is doing in a /debian instead of a /DEBIAN folder. But this
has nothing to do with whether, when, or how the bug at hand should be
fixed.

Henning

> Cheers,
> Claudius
> 

Re: [RFC PATCH 0/1] Special debian depends entries

[Claudius Heine]

[-- Attachment #1: Type: text/plain, Size: 5469 bytes --]

On Thu, 2017-12-14 at 17:20 +0100, Henning Schild wrote:
> Am Thu, 14 Dec 2017 15:52:18 +0100
> schrieb Claudius Heine <ch@denx.de>:
> 
> > On Thu, 2017-12-14 at 15:36 +0100, Henning Schild wrote:
> > > Am Thu, 14 Dec 2017 15:12:37 +0100
> > > schrieb Claudius Heine <ch@denx.de>:
> > >   
> > > > Hi Henning,
> > > > 
> > > > On Thu, 2017-12-14 at 14:42 +0100, Henning Schild wrote:  
> > > > > Am Wed, 13 Dec 2017 17:07:09 +0100
> > > > > schrieb "[ext] claudius.heine.ext@siemens.com"
> > > > > <claudius.heine.ext@siemens.com>:
> > > > >     
> > > > > > From: Claudius Heine <ch@denx.de>
> > > > > > 
> > > > > > Hi,
> > > > > > 
> > > > > > this patch is to start the discussion about how to
> > > > > > implement
> > > > > > the
> > > > > > debian depends.
> > > > > > 
> > > > > > Instead of going the just 'echo ${DEBIAN_DEPENDS}' route, I
> > > > > > chose
> > > > > > to
> > > > > > be backwards compatible. Another reason for this is also
> > > > > > for
> > > > > > the
> > > > > > possible next feature where ISAR 'DEPENDS' or 'RDEPENDS'
> > > > > > will
> > > > > > be
> > > > > > converted to the package specific 'DEBIAN_DEPENDS'.    
> > > > > 
> > > > > With the current nature of dpkg-raw DEPENDS and RDEPENDS make
> > > > > no
> > > > > sense.
> > > > > Maybe some day the class will do more than just wrap stuff in
> > > > > a
> > > > > package, but at the moment i do not see that coming.
> > > > > And even if that ever happened the class could take care of
> > > > > turning
> > > > > the
> > > > > bitbake-list (R)DEPENDS into a Debian comma-seperated list.
> > > > > 
> > > > > I tried your code in a bash (not in Isar/bitbake etc.) and i
> > > > > got
> > > > > a
> > > > > few
> > > > > more commas that i would have expected.
> > > > > 
> > > > > 'libc, (>=, 2.16)', 'tar, |, bsdtar', systemd
> > > > > 
> > > > > Shell code is nasty, i think i do not even want to know why
> > > > > it
> > > > > worked for you or wether it would work in Isar with my build
> > > > > env.    
> > > > 
> > > > I works in here because the ${DEBIAN_DEPENDS} is inserted by
> > > > bitbake
> > > > before any shell is executed. So in shell code for this example
> > > > looks
> > > > like this:
> > > > 
> > > >     DEBIAN_DEPS="$(for i in 'libc (>= 2.16)' 'tar | bsdtar'
> > > > systemd;do
> > > > echo $i,;done|tr '\n' ' '|sed 's/, *$//')"
> > > > 
> > > > If you try that out with your shell:
> > > > 
> > > >     $ echo "$(for i in 'libc (>= 2.16)' 'tar | bsdtar'
> > > > systemd;do
> > > > echo
> > > > $i,;done|tr '\n' ' '|sed 's/, *$//')"
> > > >     libc (>= 2.16), tar | bsdtar, systemd
> > > > 
> > > > It works correctly just like in bitbake.
> > > > 
> > > > DEBIAN_DEPENDS is not a shell variable but a bitbake one.
> > > > 
> > > > But I get your point that this is confusing and error-prone.
> > > > Doing
> > > > it
> > > > with python might be easier.  
> > > 
> > > It is just one of multiple points.
> > > 
> > > Could you live with the simple solution of just taking the string
> > > from
> > > the recipe and requiring recipe-updates?  
> > 
> > I would rather not break backward compatibility.
> > 
> > I know that isar is not at a stage were a fancy idea like this one
> > really matters, but for me this issue is currently not important
> > enough to justify this breakage and the work to change all the
> > recipes relying on the old behavior.
> 
> How many recipes are we talking about here 3-5 in your layer? Let us
> please not make this about principle but just be pragmatic about it.
> The change to the recipes is trivial! I will come over to your desk
> and
> help you with it, but only if you are doing the 15+ on my side ;).
> 
> Christian said he wants to be able to express versions and choices
> and
> does not care about compatibility. And so far i did not hear any
> other
> complaints.
> 
> To me it is the perfect time to take the issue seriously. Because now
> we can still change the interface without making too many people
> angry.
> 
> > So for me we either fix it in a compatible way, like my patch does,
> > or
> > don't bother and wait for a usecase where we cannot advice the user
> > to
> > just debianize the sources in some way.
> 
> No, Christian identified a bug that should be fixed.
> 
> You can always debianize sources, you could probably do everything
> that
> dpkg-raw is doing in a /debian instead of a /DEBIAN folder. But this
> has nothing to do with whether, when, or how the bug at hand should
> be
> fixed.

You haven't given any advantages to having a comma seperated list in
the DEBIAN_DEPENDS yet. Ok, you don't like the shell code, fine. But if
I invest the about same time that it takes to fixing all my 5 recipes
into writing the same transformation I did in python and have a
compatible fix for this issue, isn't that better than having an
incompatible fix?

For me its about pragmatism not about principles. Just fix the code at
one place and not in many. :)

Cheers,
Claudius

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de

            PGP key: 6FF2 E59F 00C6 BC28 31D8 64C1 1173 CB19 9808 B153
                              Keyserver: hkp://pool.sks-keyservers.net

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [RFC PATCH 0/1] Special debian depends entries

[Henning Schild]

Am Thu, 14 Dec 2017 18:02:00 +0100
schrieb Claudius Heine <ch@denx.de>:

> On Thu, 2017-12-14 at 17:20 +0100, Henning Schild wrote:
> > Am Thu, 14 Dec 2017 15:52:18 +0100
> > schrieb Claudius Heine <ch@denx.de>:
> >   
> > > On Thu, 2017-12-14 at 15:36 +0100, Henning Schild wrote:  
> > > > Am Thu, 14 Dec 2017 15:12:37 +0100
> > > > schrieb Claudius Heine <ch@denx.de>:
> > > >     
> > > > > Hi Henning,
> > > > > 
> > > > > On Thu, 2017-12-14 at 14:42 +0100, Henning Schild wrote:    
> > > > > > Am Wed, 13 Dec 2017 17:07:09 +0100
> > > > > > schrieb "[ext] claudius.heine.ext@siemens.com"
> > > > > > <claudius.heine.ext@siemens.com>:
> > > > > >       
> > > > > > > From: Claudius Heine <ch@denx.de>
> > > > > > > 
> > > > > > > Hi,
> > > > > > > 
> > > > > > > this patch is to start the discussion about how to
> > > > > > > implement
> > > > > > > the
> > > > > > > debian depends.
> > > > > > > 
> > > > > > > Instead of going the just 'echo ${DEBIAN_DEPENDS}' route,
> > > > > > > I chose
> > > > > > > to
> > > > > > > be backwards compatible. Another reason for this is also
> > > > > > > for
> > > > > > > the
> > > > > > > possible next feature where ISAR 'DEPENDS' or 'RDEPENDS'
> > > > > > > will
> > > > > > > be
> > > > > > > converted to the package specific 'DEBIAN_DEPENDS'.      
> > > > > > 
> > > > > > With the current nature of dpkg-raw DEPENDS and RDEPENDS
> > > > > > make no
> > > > > > sense.
> > > > > > Maybe some day the class will do more than just wrap stuff
> > > > > > in a
> > > > > > package, but at the moment i do not see that coming.
> > > > > > And even if that ever happened the class could take care of
> > > > > > turning
> > > > > > the
> > > > > > bitbake-list (R)DEPENDS into a Debian comma-seperated list.
> > > > > > 
> > > > > > I tried your code in a bash (not in Isar/bitbake etc.) and i
> > > > > > got
> > > > > > a
> > > > > > few
> > > > > > more commas that i would have expected.
> > > > > > 
> > > > > > 'libc, (>=, 2.16)', 'tar, |, bsdtar', systemd
> > > > > > 
> > > > > > Shell code is nasty, i think i do not even want to know why
> > > > > > it
> > > > > > worked for you or wether it would work in Isar with my build
> > > > > > env.      
> > > > > 
> > > > > I works in here because the ${DEBIAN_DEPENDS} is inserted by
> > > > > bitbake
> > > > > before any shell is executed. So in shell code for this
> > > > > example looks
> > > > > like this:
> > > > > 
> > > > >     DEBIAN_DEPS="$(for i in 'libc (>= 2.16)' 'tar | bsdtar'
> > > > > systemd;do
> > > > > echo $i,;done|tr '\n' ' '|sed 's/, *$//')"
> > > > > 
> > > > > If you try that out with your shell:
> > > > > 
> > > > >     $ echo "$(for i in 'libc (>= 2.16)' 'tar | bsdtar'
> > > > > systemd;do
> > > > > echo
> > > > > $i,;done|tr '\n' ' '|sed 's/, *$//')"
> > > > >     libc (>= 2.16), tar | bsdtar, systemd
> > > > > 
> > > > > It works correctly just like in bitbake.
> > > > > 
> > > > > DEBIAN_DEPENDS is not a shell variable but a bitbake one.
> > > > > 
> > > > > But I get your point that this is confusing and error-prone.
> > > > > Doing
> > > > > it
> > > > > with python might be easier.    
> > > > 
> > > > It is just one of multiple points.
> > > > 
> > > > Could you live with the simple solution of just taking the
> > > > string from
> > > > the recipe and requiring recipe-updates?    
> > > 
> > > I would rather not break backward compatibility.
> > > 
> > > I know that isar is not at a stage were a fancy idea like this one
> > > really matters, but for me this issue is currently not important
> > > enough to justify this breakage and the work to change all the
> > > recipes relying on the old behavior.  
> > 
> > How many recipes are we talking about here 3-5 in your layer? Let us
> > please not make this about principle but just be pragmatic about it.
> > The change to the recipes is trivial! I will come over to your desk
> > and
> > help you with it, but only if you are doing the 15+ on my side ;).
> > 
> > Christian said he wants to be able to express versions and choices
> > and
> > does not care about compatibility. And so far i did not hear any
> > other
> > complaints.
> > 
> > To me it is the perfect time to take the issue seriously. Because
> > now we can still change the interface without making too many people
> > angry.
> >   
> > > So for me we either fix it in a compatible way, like my patch
> > > does, or
> > > don't bother and wait for a usecase where we cannot advice the
> > > user to
> > > just debianize the sources in some way.  
> > 
> > No, Christian identified a bug that should be fixed.
> > 
> > You can always debianize sources, you could probably do everything
> > that
> > dpkg-raw is doing in a /debian instead of a /DEBIAN folder. But this
> > has nothing to do with whether, when, or how the bug at hand should
> > be
> > fixed.  
> 
> You haven't given any advantages to having a comma seperated list in
> the DEBIAN_DEPENDS yet. Ok, you don't like the shell code, fine. But
> if I invest the about same time that it takes to fixing all my 5
> recipes into writing the same transformation I did in python and have
> a compatible fix for this issue, isn't that better than having an
> incompatible fix?

The benefit is obvious, reduced complexity and everything that comes
with it. Code is error prone, so replacing code with "no code" is
clearly a good idea. The only reason we are having this discussion is
because of just one line of code that looked harmless at the time of
writing.

> For me its about pragmatism not about principles. Just fix the code at
> one place and not in many. :)

No, delete the broken code and hope you get it right this time. And "no
code" is very likely to have less bugs than any positive number of
"code".

Henning
 
> Cheers,
> Claudius
> 

Re: [RFC PATCH 0/1] Special debian depends entries

[Claudius Heine]

[-- Attachment #1: Type: text/plain, Size: 7563 bytes --]

On Thu, 2017-12-14 at 18:31 +0100, Henning Schild wrote:
> Am Thu, 14 Dec 2017 18:02:00 +0100
> schrieb Claudius Heine <ch@denx.de>:
> 
> > On Thu, 2017-12-14 at 17:20 +0100, Henning Schild wrote:
> > > Am Thu, 14 Dec 2017 15:52:18 +0100
> > > schrieb Claudius Heine <ch@denx.de>:
> > >   
> > > > On Thu, 2017-12-14 at 15:36 +0100, Henning Schild wrote:  
> > > > > Am Thu, 14 Dec 2017 15:12:37 +0100
> > > > > schrieb Claudius Heine <ch@denx.de>:
> > > > >     
> > > > > > Hi Henning,
> > > > > > 
> > > > > > On Thu, 2017-12-14 at 14:42 +0100, Henning Schild
> > > > > > wrote:    
> > > > > > > Am Wed, 13 Dec 2017 17:07:09 +0100
> > > > > > > schrieb "[ext] claudius.heine.ext@siemens.com"
> > > > > > > <claudius.heine.ext@siemens.com>:
> > > > > > >       
> > > > > > > > From: Claudius Heine <ch@denx.de>
> > > > > > > > 
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > this patch is to start the discussion about how to
> > > > > > > > implement
> > > > > > > > the
> > > > > > > > debian depends.
> > > > > > > > 
> > > > > > > > Instead of going the just 'echo ${DEBIAN_DEPENDS}'
> > > > > > > > route,
> > > > > > > > I chose
> > > > > > > > to
> > > > > > > > be backwards compatible. Another reason for this is
> > > > > > > > also
> > > > > > > > for
> > > > > > > > the
> > > > > > > > possible next feature where ISAR 'DEPENDS' or
> > > > > > > > 'RDEPENDS'
> > > > > > > > will
> > > > > > > > be
> > > > > > > > converted to the package specific
> > > > > > > > 'DEBIAN_DEPENDS'.      
> > > > > > > 
> > > > > > > With the current nature of dpkg-raw DEPENDS and RDEPENDS
> > > > > > > make no
> > > > > > > sense.
> > > > > > > Maybe some day the class will do more than just wrap
> > > > > > > stuff
> > > > > > > in a
> > > > > > > package, but at the moment i do not see that coming.
> > > > > > > And even if that ever happened the class could take care
> > > > > > > of
> > > > > > > turning
> > > > > > > the
> > > > > > > bitbake-list (R)DEPENDS into a Debian comma-seperated
> > > > > > > list.
> > > > > > > 
> > > > > > > I tried your code in a bash (not in Isar/bitbake etc.)
> > > > > > > and i
> > > > > > > got
> > > > > > > a
> > > > > > > few
> > > > > > > more commas that i would have expected.
> > > > > > > 
> > > > > > > 'libc, (>=, 2.16)', 'tar, |, bsdtar', systemd
> > > > > > > 
> > > > > > > Shell code is nasty, i think i do not even want to know
> > > > > > > why
> > > > > > > it
> > > > > > > worked for you or wether it would work in Isar with my
> > > > > > > build
> > > > > > > env.      
> > > > > > 
> > > > > > I works in here because the ${DEBIAN_DEPENDS} is inserted
> > > > > > by
> > > > > > bitbake
> > > > > > before any shell is executed. So in shell code for this
> > > > > > example looks
> > > > > > like this:
> > > > > > 
> > > > > >     DEBIAN_DEPS="$(for i in 'libc (>= 2.16)' 'tar | bsdtar'
> > > > > > systemd;do
> > > > > > echo $i,;done|tr '\n' ' '|sed 's/, *$//')"
> > > > > > 
> > > > > > If you try that out with your shell:
> > > > > > 
> > > > > >     $ echo "$(for i in 'libc (>= 2.16)' 'tar | bsdtar'
> > > > > > systemd;do
> > > > > > echo
> > > > > > $i,;done|tr '\n' ' '|sed 's/, *$//')"
> > > > > >     libc (>= 2.16), tar | bsdtar, systemd
> > > > > > 
> > > > > > It works correctly just like in bitbake.
> > > > > > 
> > > > > > DEBIAN_DEPENDS is not a shell variable but a bitbake one.
> > > > > > 
> > > > > > But I get your point that this is confusing and error-
> > > > > > prone.
> > > > > > Doing
> > > > > > it
> > > > > > with python might be easier.    
> > > > > 
> > > > > It is just one of multiple points.
> > > > > 
> > > > > Could you live with the simple solution of just taking the
> > > > > string from
> > > > > the recipe and requiring recipe-updates?    
> > > > 
> > > > I would rather not break backward compatibility.
> > > > 
> > > > I know that isar is not at a stage were a fancy idea like this
> > > > one
> > > > really matters, but for me this issue is currently not
> > > > important
> > > > enough to justify this breakage and the work to change all the
> > > > recipes relying on the old behavior.  
> > > 
> > > How many recipes are we talking about here 3-5 in your layer? Let
> > > us
> > > please not make this about principle but just be pragmatic about
> > > it.
> > > The change to the recipes is trivial! I will come over to your
> > > desk
> > > and
> > > help you with it, but only if you are doing the 15+ on my side
> > > ;).
> > > 
> > > Christian said he wants to be able to express versions and
> > > choices
> > > and
> > > does not care about compatibility. And so far i did not hear any
> > > other
> > > complaints.
> > > 
> > > To me it is the perfect time to take the issue seriously. Because
> > > now we can still change the interface without making too many
> > > people
> > > angry.
> > >   
> > > > So for me we either fix it in a compatible way, like my patch
> > > > does, or
> > > > don't bother and wait for a usecase where we cannot advice the
> > > > user to
> > > > just debianize the sources in some way.  
> > > 
> > > No, Christian identified a bug that should be fixed.
> > > 
> > > You can always debianize sources, you could probably do
> > > everything
> > > that
> > > dpkg-raw is doing in a /debian instead of a /DEBIAN folder. But
> > > this
> > > has nothing to do with whether, when, or how the bug at hand
> > > should
> > > be
> > > fixed.  
> > 
> > You haven't given any advantages to having a comma seperated list
> > in
> > the DEBIAN_DEPENDS yet. Ok, you don't like the shell code, fine.
> > But
> > if I invest the about same time that it takes to fixing all my 5
> > recipes into writing the same transformation I did in python and
> > have
> > a compatible fix for this issue, isn't that better than having an
> > incompatible fix?
> 
> The benefit is obvious, reduced complexity and everything that comes
> with it. Code is error prone, so replacing code with "no code" is
> clearly a good idea. The only reason we are having this discussion is
> because of just one line of code that looked harmless at the time of
> writing.
> 
> > For me its about pragmatism not about principles. Just fix the code
> > at
> > one place and not in many. :)
> 
> No, delete the broken code and hope you get it right this time. And
> "no
> code" is very likely to have less bugs than any positive number of
> "code".

I know you don't mean that, but that still sounds like saying "Because
we could do something wrong, do nothing instead." Not really an
argument I would follow. The idea of "The only bug free code is no
code." was to me always an argument for minimalism, reviews,
upgradeability and so on, not for replacing code with something that
does almost nothing and then having to work around that somewhere else.

I send a python based solution to the list, so we could base further
discussion on this one.

But I suspect our views are pretty much set here. So maybe we need some
third party to decide.

Cheers,
Claudius


-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de

            PGP key: 6FF2 E59F 00C6 BC28 31D8 64C1 1173 CB19 9808 B153
                              Keyserver: hkp://pool.sks-keyservers.net

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]