Re: Bug#982085: gettext: Support autobuilding on emacsless and javaless architectures
On 6 Feb 2021, at 12:24, Santiago Vila <sanvila@unex.es> wrote:
> 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.
The nojava profile is for bootstrapping, and the architecture
restriction list is for architectures where it's not ported and thus
cannot exist unless someone goes away and writes a lot of code
(generally OS-dependent, not architecture-dependent, given Zero
exists). It's a long-standing issue in Debian that there's no nice way
to deal with this; whilst you can include a .mk in your rules file to
get the list of supported architectures, you need the control file in
the source file to have the architecture restriction list. Moreover,
dpkg-dev is far too late; sbuild/pbuilder need to install the build
dependencies before running dpkg-buildpackage, and wanna-build is
checking installability before sbuild even gets invoked, so in reality
the situation just isn't going to change in the near future and this is
the only way to make things work, unless you want porters to have to
manually build gettext with the nojava profile every time a new version
is uploaded (which, in practice, ends up being every time it needs a
rebuild due to no longer being installable instead).
Jess
Reply to: