| Message ID | 20220524173622.4033177-1-alex@linutronix.de |
|---|---|
| State | Accepted, archived |
| Commit | da784aae3014d82039a5404d9b871b44ecd4aa52 |
| Headers | show |
| Series | apt: fix upstream version check | expand |
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]))
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 >
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!
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}"
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(-)