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

[Henning Schild <henning.schild@siemens.com>]

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
>