Bug#1050944: debhelper-compat level

Vladimir Petko vladimir.petko at canonical.com
Mon Sep 4 00:55:30 BST 2023


Hi,

 Yes, the main reason for keeping the old debhelper for jtreg is that
its version is kept in sync with openjdk (due to the build
requirements of openjdk). The updated versions of jtreg normally work
with older dependencies, so we do not need to upgrade them often. The
security updates (of Ubuntu and Debian) require us to publish updated
jtregX along with the openjdk and this forces us to keep the old
debhelper version.

Best Regards,
 Vladimir.

On Mon, Sep 4, 2023 at 11:48 AM tony mancill <tmancill at debian.org> wrote:
>
> 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



More information about the pkg-java-maintainers mailing list