[PATCH] apt: fix upstream version check

[PATCH] apt: fix upstream version check

[Alexander Kanavin]

Signed-off-by: Alexander Kanavin <alex@linutronix.de>
---
 meta/recipes-devtools/apt/apt_2.4.5.bb | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-devtools/apt/apt_2.4.5.bb b/meta/recipes-devtools/apt/apt_2.4.5.bb
index 95c25e3036..1d94dd118c 100644
--- a/meta/recipes-devtools/apt/apt_2.4.5.bb
+++ b/meta/recipes-devtools/apt/apt_2.4.5.bb
@@ -31,8 +31,14 @@ LIC_FILES_CHKSUM = "file://COPYING.GPL;md5=b234ee4d69f5fce4486a80fdaf4a4263"
 # the package is taken from snapshots.debian.org; that source is static and goes stale
 # so we check the latest upstream from a directory that does get updated
 UPSTREAM_CHECK_URI = "${DEBIAN_MIRROR}/main/a/apt/"
-
-inherit cmake perlnative bash-completion upstream-version-is-even useradd
+# apt seems to follow a peculiar version policy, where every *other* even version
+# is considered stable, e.g. 1.0, 1.4, 1.8, 2.2, 2.6, etc. As there is no way
+# to express 'divisible by 4 plus 2' in regex (that I know of), let's hardcode a few.
+UPSTREAM_CHECK_REGEX = "[^\d\.](?P<pver>((2\.2)|(2\.6)|(3\.0)|(3\.4)|(3\.8)|(4\.2))(\.\d+)+)\.tar"
+# needs be marked as unknown until 2.6 is out
+UPSTREAM_VERSION_UNKNOWN = "1"
+
+inherit cmake perlnative bash-completion useradd
 
 # User is added to allow apt to drop privs, will runtime warn without
 USERADD_PACKAGES = "${PN}"
-- 
2.30.2

Re: [OE-core] [PATCH] apt: fix upstream version check

[Luca Ceresoli]

Hi Alex,

Il giorno Tue, 24 May 2022 19:36:22 +0200
"Alexander Kanavin" <alex.kanavin@gmail.com> ha scritto:

> Signed-off-by: Alexander Kanavin <alex@linutronix.de>
> ---
>  meta/recipes-devtools/apt/apt_2.4.5.bb | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/recipes-devtools/apt/apt_2.4.5.bb b/meta/recipes-devtools/apt/apt_2.4.5.bb
> index 95c25e3036..1d94dd118c 100644
> --- a/meta/recipes-devtools/apt/apt_2.4.5.bb
> +++ b/meta/recipes-devtools/apt/apt_2.4.5.bb
> @@ -31,8 +31,14 @@ LIC_FILES_CHKSUM = "file://COPYING.GPL;md5=b234ee4d69f5fce4486a80fdaf4a4263"
>  # the package is taken from snapshots.debian.org; that source is static and goes stale
>  # so we check the latest upstream from a directory that does get updated
>  UPSTREAM_CHECK_URI = "${DEBIAN_MIRROR}/main/a/apt/"
> -
> -inherit cmake perlnative bash-completion upstream-version-is-even useradd
> +# apt seems to follow a peculiar version policy, where every *other* even version
> +# is considered stable, e.g. 1.0, 1.4, 1.8, 2.2, 2.6, etc. As there is no way
> +# to express 'divisible by 4 plus 2' in regex (that I know of), let's hardcode a few.

Or, "how to reinvent the wheel in order to uselessly complicate other
people's lives".

I'm taking your patch for testing, but I have a question.

Is this  policy documented? If so, IMO a URL here would be nice.
Otherwise, is it wise to encode future stable releases here without
really knowing whether the practice seen so far will go on in the
future?

> +UPSTREAM_CHECK_REGEX = "[^\d\.](?P<pver>((2\.2)|(2\.6)|(3\.0)|(3\.4)|(3\.8)|(4\.2))(\.\d+)+)\.tar"

Maybe this would be more generic (untested):

  (([2468\.[26])|([3579]\.[048]))

-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [OE-core] [PATCH] apt: fix upstream version check

[Alexander Kanavin]

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

I haven’t seen it written explicitly, it comes from what stable Debian
releases actually carry. There’s no harm in having a check that’s too
strict, but there is harm in updating to versions that are actually
intended for testing or unstable (and that’s what 2.4 is).

Alex

On Wed 25. May 2022 at 10.29, Luca Ceresoli <luca.ceresoli@bootlin.com>
wrote:

> Hi Alex,
>
> Il giorno Tue, 24 May 2022 19:36:22 +0200
> "Alexander Kanavin" <alex.kanavin@gmail.com> ha scritto:
>
> > Signed-off-by: Alexander Kanavin <alex@linutronix.de>
> > ---
> >  meta/recipes-devtools/apt/apt_2.4.5.bb | 10 ++++++++--
> >  1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/meta/recipes-devtools/apt/apt_2.4.5.bb
> b/meta/recipes-devtools/apt/apt_2.4.5.bb
> > index 95c25e3036..1d94dd118c 100644
> > --- a/meta/recipes-devtools/apt/apt_2.4.5.bb
> > +++ b/meta/recipes-devtools/apt/apt_2.4.5.bb
> > @@ -31,8 +31,14 @@ LIC_FILES_CHKSUM =
> "file://COPYING.GPL;md5=b234ee4d69f5fce4486a80fdaf4a4263"
> >  # the package is taken from snapshots.debian.org; that source is
> static and goes stale
> >  # so we check the latest upstream from a directory that does get updated
> >  UPSTREAM_CHECK_URI = "${DEBIAN_MIRROR}/main/a/apt/"
> > -
> > -inherit cmake perlnative bash-completion upstream-version-is-even
> useradd
> > +# apt seems to follow a peculiar version policy, where every *other*
> even version
> > +# is considered stable, e.g. 1.0, 1.4, 1.8, 2.2, 2.6, etc. As there is
> no way
> > +# to express 'divisible by 4 plus 2' in regex (that I know of), let's
> hardcode a few.
>
> Or, "how to reinvent the wheel in order to uselessly complicate other
> people's lives".
>
> I'm taking your patch for testing, but I have a question.
>
> Is this  policy documented? If so, IMO a URL here would be nice.
> Otherwise, is it wise to encode future stable releases here without
> really knowing whether the practice seen so far will go on in the
> future?
>
> > +UPSTREAM_CHECK_REGEX =
> "[^\d\.](?P<pver>((2\.2)|(2\.6)|(3\.0)|(3\.4)|(3\.8)|(4\.2))(\.\d+)+)\.tar"
>
> Maybe this would be more generic (untested):
>
>   (([2468\.[26])|([3579]\.[048]))
>
> --
> Luca Ceresoli, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>

[-- Attachment #2: Type: text/html, Size: 3504 bytes --]

Re: [OE-core] [PATCH] apt: fix upstream version check

[Luca Ceresoli]

Hi Alex,

Il giorno Wed, 25 May 2022 13:01:23 +0200
"Alexander Kanavin" <alex.kanavin@gmail.com> ha scritto:

> I haven’t seen it written explicitly, it comes from what stable Debian
> releases actually carry. There’s no harm in having a check that’s too
> strict, but there is harm in updating to versions that are actually
> intended for testing or unstable (and that’s what 2.4 is).

Ok, thanks for the clarification!

-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com