XPost: linux.debian.bugs.dist

On Sat, Feb 06, 2021 at 12:34:07PM +0000, Jessica Clarke wrote:

unless you want porters to have to
manually build gettext with the nojava profile every time a new version
is uploaded

The reverse of that would be: "Unless you want every package
maintainer to manually track the java stuff every time a new
architecture becomes java-enabled or java-disabled).

I think there are less people porting than people maintaining packages
using "nojava", so yes, I think porters defining nojava in their
environments would be a much better solution.

Thanks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.bugs.dist

On Sat, Feb 06, 2021 at 12:04:30PM +0000, Jessica Clarke wrote:

Source: gettext
Version: 0.21-4
Severity: important
Tags: patch

Hi,
Currently gettext Build-Depends on dh-elpa (which Depends on emacs) and default-jdk, so architectures that lack one or more of emacs and openjdk
are unable to build gettext (whilst there is now a nojava build profile,
that does not help autobuilding where all builds are done without any
build profiles). I have attached a patch which (a) moves dh-elpa to Build-Depends-Indep as it's only needed for gettext-el (b) adds
architecture restriction lists to the java build dependencies based on
the list of supported architectures in the latest openjdk. Please
consider applying and uploading this soon, since after the libcroco3
removal gettext is no longer installable on many ports architectures and
is not able to be rebuilt due to the issues addressed in this patch.

Thanks a lot for the patch, but I will only accept the first part.

In my opinion, it makes no sense that individual packages have to
track when and when not is java available if it's supposed to be a
bootstrap problem.

If it's not supposed to be a bootstrap problem and also there is no
way to define nojava in a centralized way, then, in my opinion, it
makes no sense that "nojava" exist at all.

Maybe dpkg developers could help here by enabling/disabling nojava
centrally in dpkg-dev. Cc:ing them.

Thanks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.bugs.dist

On 6 Feb 2021, at 12:44, Santiago Vila <sanvila@unex.es> wrote:

On Sat, Feb 06, 2021 at 12:34:07PM +0000, Jessica Clarke wrote:

unless you want porters to have to
manually build gettext with the nojava profile every time a new version
is uploaded

The reverse of that would be: "Unless you want every package
maintainer to manually track the java stuff every time a new
architecture becomes java-enabled or java-disabled).

I think there are less people porting than people maintaining packages
using "nojava", so yes, I think porters defining nojava in their
environments would be a much better solution.

I would love for you to not have to. But like I said, that creates
unbounded work for me as a porter, and I'm providing a patch for you
that works so there is no work needed on your part. If the list ever
changes, that's the responsibility of the porter for the architecture
in question. But "defining nojava in [my] environment" does not solve
the problem as I explained in the text that you unhelpfully trimmed; wanna-build does not know and so the package will never be autobuilt.
Many other packages in the archive are happy to apply these patches we
provide, I don't get why you're so unwilling to do the same when it'll
only ever change due to changes in debian-ports that we'll provide
patches for. I'm not asking you to do any more tracking than "porter
provides patch -> run patch -p1".

Jess

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)