Bug#1050944: debhelper-compat level

[tony mancill]

Hi Vladimir,

Definitely no need for you to apologize.  I hope my tone didn't come
across as aggressive.  My goal is merely to establish what we (meaning,
the Java Team) should take into consideration for backports.  Based on
the exchange so far, it appears
that we want to keep jtreg6 (and all other direct build-deps for
openjdk-${x}) at debhelper 11 for as long as Ubuntu bionic receives
security support , but that transitive build-deps, for example
libhamcrest-java, can be upgraded without causing problems.  Does that
capture the rationale correctly?

By the way, the reason we bump debhelper-compat is because some of the
Debian Java tooling behaves differently at the older compatibility
versions, and so keeping things consistent and current means fewer
exceptions in package build behavior.

Specifically, gradle-debian-helper doesn't automatically run tests at
debhelper-compat 11, but does at dh 13 [1].  This is one response to
Matthias' question "is there any reason to use debhelper 13?" in May of
2021 [2].  (Yes, because gradle-debian-helper behaves differently in
debhelper 13 since November of 2019.)

I will make a note in the jtreg6 README.source as to why we want to stay
with debhelper 11.

Thanks!
tony

[1] https://salsa.debian.org/java-team/gradle-debian-helper/-/commit/9417606c1ffaed9571045cb055f80350783c0555
[2] https://lists.debian.org/debian-java/2021/05/msg00012.html

On Sun, Sep 03, 2023 at 05:33:36PM +1200, Vladimir Petko wrote:
> Hi,
> 
>  I apologise for my earlier comment being too vague and in the wrong
> tone and mentioning a completely wrong (or misleading) thing. We do
> openjdk security updates in -security pocket in Ubuntu and according
> to security team FAQ[1] the updates are built with -release and
> -security pockets. The updated debhelper is present in the backports
> pocket which is not used by the security team for security updates.
> This means that we are stuck with the older (11) debhelper version in
> order to build security updates for bionic and up.
> 
> Best Regards,
>  Vladimir.
> 
> [1] https://wiki.ubuntu.com/SecurityTeam/FAQ#How_are_the_.22-updates.22_and_.22-security.22_pockets_different.3F
> 
> On Sun, Sep 3, 2023 at 5:41 AM tony mancill <tmancill at debian.org> wrote:
> >
> > Hi Matthias,
> >
> > On Fri, Sep 01, 2023 at 07:19:15AM -0700, tony mancill wrote:
> > > On Fri, Sep 01, 2023 at 07:04:05PM +1200, Vladimir Petko wrote:
> > > >  The debhelper-compat was intentionally set to >=11 in order to
> > > > support backports.
> > >
> > > Thank you for the reminder.  I can easily revert the change.  But to
> > > make sure I understand the requirements, how far back do we want to
> > > support backports of new uploads of jtreg6?
> > >
> > > Although it wasn't part of the buster release, debhelper 13.x is
> > > available in old-old-stable (buster) backports [0,1], which is as far as
> > > I looked before making the change.  Is jtreg6 needed for stretch, which
> > > is currently in EOL ELTS [2]?
> > >
> > > Thank you,
> > > tony
> > >
> > > [0] https://packages.debian.org/source/buster-backports/debhelper
> > > [1] https://packages.debian.org/source/oldoldstable-backports/debhelper
> > > [2] https://wiki.debian.org/DebianReleases
> >
> > Thank you for the upload.  As I mentioned to Vladimir above, I'd like to
> > document the reason debhelper 13 is not backport friendly.  If you can
> > give me a pointer or a brief explanation, I'll add it to README.source
> > so it's clear to all.  (I assume it has to do with releases older than
> > Debian buster or Ubuntu focal [3], since both of their backport suites
> > already contain debhelper 13.)
> >
> > Also, there are build-deps of jtreg6, for example libhamcrest-java [4]
> > that depend on debhelper-compat 13 and presumably need to be adjusted as
> > well.
> >
> > Thanks,
> > tony
> >
> > [3] https://packages.ubuntu.com/search?suite=default&section=all&arch=any&keywords=debhelper&searchon=sourcenames
> > [4] https://salsa.debian.org/java-team/libhamcrest-java/-/blob/master/debian/control#L10
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-java-maintainers/attachments/20230903/6bc4fff3/attachment.sig>