Re: Bug#982085: gettext: Support autobuilding on emacsless and javaless architectures
On 6 Feb 2021, at 12:44, Santiago Vila wrote: > > On Sat, Feb 06, 2021 at 12:34:07PM +, 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
Re: Bug#982085: gettext: Support autobuilding on emacsless and javaless architectures
On Sat, Feb 06, 2021 at 12:34:07PM +, 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.
Re: Bug#982085: gettext: Support autobuilding on emacsless and javaless architectures
On 6 Feb 2021, at 12:24, Santiago Vila wrote: > On Sat, Feb 06, 2021 at 12:04:30PM +, 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
Re: Bug#982085: gettext: Support autobuilding on emacsless and javaless architectures
On Sat, Feb 06, 2021 at 12:04:30PM +, 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.
