Re: [PATCH] meta-isar: hello: Use <orig-version> in CHANGELOG_V

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

Hi,

here some notes on a PV pattern for "tracking"

- choose a pattern that bitbake can order in case of multiple recipes
  for one package release < master < next
  2.0 < 9999 < 99999, using strings instead of numbers might not allow
  bitbake to order
- choose a pattern that people see as "tracking"
- that PV would only be used in bitbake, the DEBIAN_V would come from
  the code and might be partially constructed with isar patchlevels
- look at how oe chooses its PV for "tracking", if it does not support
  that, look at gentoo
- use the pattern across all recipes, no matter how they fetch

Henning

Am Wed, 29 Apr 2020 08:37:20 +0200
schrieb "[ext] Henning Schild" <henning.schild@siemens.com>:

> Am Wed, 29 Apr 2020 08:27:24 +0200
> schrieb "[ext] Henning Schild" <henning.schild@siemens.com>:
> 
> > Am Wed, 29 Apr 2020 08:10:07 +0200
> > schrieb Jan Kiszka <jan.kiszka@siemens.com>:
> >   
> > > On 29.04.20 07:54, Henning Schild wrote:    
> > > > Am Tue, 28 Apr 2020 18:01:53 +0200
> > > > schrieb Jan Kiszka <jan.kiszka@siemens.com>:
> > > >       
> > > >> On 28.04.20 18:00, Henning Schild wrote:      
> > > >>> I think with this we might be able to put everything into one
> > > >>> .bb. At the moment we have the inc plus two bbs that have PV
> > > >>> in their names.
> > > >>>
> > > >>> Taking PV from a bb filename is wrong when the inc uses
> > > >>> <orig-version>.      
> > > >>
> > > >> "We cannot consolidate the recipes carrying the upstream
> > > >> versions, though, as that information needs to be propagated
> > > >> into ${S}."      
> > > > 
> > > > I read that but did not fully understand it. If we can not do
> > > > that or fully do that, does that mean the tracking of
> > > > "<orig-version>" can not be fully implemented? Maybe we can
> > > > fill the gaps or document them. To me it sounds like a
> > > > "half-feature" to introduce orig-version as proposed.      
> > > 
> > > We have two problems to solve here:
> > > 
> > >   - appending to the exact debian version our own suffix when
> > > patching it
> > >   - tracking the upstream version under which the source package
> > > is extracted to so that ${S} is set correctly
> > > 
> > > The former is addressed by my patch to debianize, for the latter
> > > I'm lacking a good idea. However, that is generally not a bit
> > > issue because Debian does less frequently the update of the major
> > > version, often only when switching its own major release. Also,
> > > patches you carry are more likely to require adjustments anyway
> > > in that case.
> > > 
> > > The problem for setting S is not the version extraction like we do
> > > for the changelog. It is that this has to happen rather early -
> > > but after recipe parsing where it normally happens. It would
> > > require to rewrite do_apt_fetch so that it identifies the path
> > > and sets S, somehow.    
> > 
> > But S can be anything, it is a temporary directory ... afaik.
> > 
> > We have S="${WORKDIR}/git", why not have
> > S="${WORKDIR}/${PN}-orig-version" ... really that string and no
> > substitution later on. Or even PN-42-nobody-cares
> > 
> > I might be wrong, got a little lost in S and D in isar and still
> > have those gentoo meanings in my head. But i guess it should be the
> > same as in gentoo.  
> 
> gentoo uses PV=9999 for "tracking", the real number will come out of
> the code you fetch .. i.e. with git. Some packages require more 9s,
> the idea is to have the tracking recipe always be the most recent.
> And all those 9s tell devs in the filename that it is the tracking
> one. In fact it might even be the "same" recipe there.
> 
> https://github.com/gentoo/gentoo/blob/master/net-vpn/openconnect/openconnect-9999.ebuild
> 
> is basically the same as
> 
> https://github.com/gentoo/gentoo/blob/master/net-vpn/openconnect/openconnect-8.08.ebuild
> 
> So we want to use <orig-version> for when we fetch with apt:// but we
> might want a PV-pattern that also covers git fetching or tarball
> fetching.
> 
> I.e. in jailhouse the recipe could git fetch the tag when PV looks
> like a release. And if PV looks like tracking it could take latest
> master or next. Same recipe, just a different filename.
> 
> Whatever works there should be taken for the apt://-fetcher as well,
> not different PV pattern depending on the fetcher.
> 
> Henning
> 
> > Henning
> >   
> > > Jan
> > >     
> > > > 
> > > > Henning
> > > >       
> > > >> Jan
> > > >>      
> > > >>> Henning
> > > >>>
> > > >>> On Thu, 23 Apr 2020 19:29:11 +0200
> > > >>> Jan Kiszka <jan.kiszka@siemens.com> wrote:
> > > >>>          
> > > >>>> From: Jan Kiszka <jan.kiszka@siemens.com>
> > > >>>>
> > > >>>> Make use of the new placeholder to append "+isar" to the
> > > >>>> original version. We cannot consolidate the recipes carrying
> > > >>>> the upstream versions, though, as that information needs to
> > > >>>> be propagated into ${S}.
> > > >>>>
> > > >>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> > > >>>> ---
> > > >>>>
> > > >>>> Depends on
> > > >>>> https://groups.google.com/d/msgid/isar-users/ebf1ab25-74ea-b3ba-4c48-2ecac873c6f7%40siemens.com
> > > >>>>
> > > >>>>    meta-isar/recipes-app/hello/hello.inc | 2 +-
> > > >>>>    1 file changed, 1 insertion(+), 1 deletion(-)
> > > >>>>
> > > >>>> diff --git a/meta-isar/recipes-app/hello/hello.inc
> > > >>>> b/meta-isar/recipes-app/hello/hello.inc index
> > > >>>> c5f322bb..d81085d8 100644 ---
> > > >>>> a/meta-isar/recipes-app/hello/hello.inc +++
> > > >>>> b/meta-isar/recipes-app/hello/hello.inc @@ -11,7 +11,7 @@
> > > >>>> inherit dpkg SRC_URI = "apt://${PN}"
> > > >>>>    
> > > >>>>    MAINTAINER = "isar-users <isar-users@googlegroups.com>"
> > > >>>> -CHANGELOG_V = "${PV}-99+isar"
> > > >>>> +CHANGELOG_V = "<orig-version>+isar"
> > > >>>>    
> > > >>>>    do_prepare_build() {
> > > >>>>    	deb_add_changelog      
> > > >>>          
> > > >>
> > > >>      
> > > >       
> > >     
> >   
>