1. Forum
  2. Usenet
  3. LINUX.DEBIAN.MAINT.DPKG

  • Bug#982085: gettext: Support autobuilding on emacsless and javaless arc

    From Santiago Vila@21:1/5 to Jessica Clarke on Sat Feb 6 13:50:02 2021
    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)
  • From Santiago Vila@21:1/5 to Jessica Clarke on Sat Feb 6 13:40:02 2021
    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)
  • From Jessica Clarke@21:1/5 to Santiago Vila on Sat Feb 6 14:00:01 2021
    XPost: linux.debian.bugs.dist

    On 6 Feb 2021, at 12:44, Santiago Vila <[email protected]> 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)