Bug#692274:
Any news on this? As explained in Debian bug #796497, ruby-ronn, a pure Ruby manpage authoring tool, depends on the obsolete ruby-hpricot parser which will not be shipped with stretch. Since a lot of packages use ruby-ronn for their manpages, it would be great to have an asciidoc-man package which would make the transition from ronn to asciidoc much simpler.
Bug#692274: asciidoc packages splitting
Hi, Indeed, I think that having only one backend by package might become quite quickly a nightmare to maintain. So here is what I propose: - asciidoc-data (contains common tools, filters, lang files, backends = data from /usr/share/asciidoc/, /etc/asciidoc/) - No dependencies - asciidoc-minimal (contains python files = /usr/share/asciidoc/asciidocapi.py, /usr/bin/*) - Depends on python and asciidoc-data and recommends libxml2-utils, xmlto (you're able to generate man pages, xhtml using a2x and html files using asciidoc and maybe others, have to test) = recommends less than 25M of dependencies over the current 700M - asciidoc-doc (basically containing data from /usr/share/doc/asciidoc/*/ and man pages) - Depends on asciidoc-data - asciidoc-dblatex (a meta package to get the dependencies required for further document processing using dblatex) - Depends on asciidoc-minimal, docbook-utils, dblatex and suggests on epubcheck, source-highlight - asciidoc-fop (a meta package to get the dependencies required for further document processing using fop) - Depends on asciidoc-minimal, docbook-utils, fop and suggests on epubcheck, source-highlight - asciidoc would be a meta package installing asciidoc-data, asciidoc-minimal, asciidoc-doc, asciidoc-dblatex and vim-asciidoc (keeping the current style of the package for users not to be lost after the upgrade) I'll also trigger an apt-listchanges NEWS file to indicate those splits. I'm not sure what the docbook-utils dependency is used for but as I was able to generate html documents and man pages after removing it so put only with dblatex and fop packages. Still have to check that. Would that sound a good start for you? Thanks in advance, Joseph -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692274: asciidoc packages splitting
On Thu, 18 Sep 2014, Joseph Herlant wrote: Hi Joseph, just a few notes. Indeed, I think that having only one backend by package might become quite quickly a nightmare to maintain. So here is what I propose: - asciidoc-data (contains common tools, filters, lang files, backends = data from /usr/share/asciidoc/, /etc/asciidoc/) - No dependencies I would prefer -common as package name - asciidoc-minimal (contains python files = /usr/share/asciidoc/asciidocapi.py, /usr/bin/*) - Depends on python and asciidoc-data and recommends libxml2-utils, xmlto (you're able to generate man pages, xhtml using a2x and html files using asciidoc and maybe others, have to test) = recommends less than 25M of dependencies over the current 700M -base is probably better. - asciidoc-doc (basically containing data from /usr/share/doc/asciidoc/*/ and man pages) - Depends on asciidoc-data fine - asciidoc-dblatex (a meta package to get the dependencies required for further document processing using dblatex) - Depends on asciidoc-minimal, docbook-utils, dblatex and suggests on epubcheck, source-highlight fine - asciidoc-fop (a meta package to get the dependencies required for further document processing using fop) - Depends on asciidoc-minimal, docbook-utils, fop and suggests on epubcheck, source-highlight fine - asciidoc would be a meta package installing asciidoc-data, asciidoc-minimal, asciidoc-doc, asciidoc-dblatex and vim-asciidoc (keeping the current style of the package for users not to be lost after the upgrade) ack Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692274: asciidoc packages splitting
Hi Alex, Great, thanks for the notes. That makes totally sense. I'll go on with the split. Joseph -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692274: asciidoc packages splitting
I'd also add an asciidoc-tests where I would put the data about the testasciidoc binary (and its /etc/asciidoc/data/*) if you're ok with that. I don't think anyone really uses that anyway, but we might use it for dep-8 testing in the future. Best, Joseph On Thu, Sep 18, 2014 at 4:02 PM, Joseph Herlant herla...@gmail.com wrote: Hi Alex, Great, thanks for the notes. That makes totally sense. I'll go on with the split. Joseph -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692274: asciidoc packages splitting
Control: tags -1 + pending Hi, I've done the split with the proposed organization (just put the filters in the -base instead of the -common as they are python code based). Pushed the change to the git repo. If you want any changes to this, please tell me. Best, Joseph -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692274: asciidoc packages splitting
Control: tags -1 + moreinfo Hi, For information, I began the split of asciidoc to have a package that's easier to understand and maintain (see #729242). Did you have the time to consider the list of the packages you'd like to have? Best, Joseph -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692274: asciidoc packages splitting
On Tue, Sep 16, 2014 at 4:45 PM, Joseph Herlant herla...@gmail.com wrote: Control: tags -1 + moreinfo Hi, For information, I began the split of asciidoc to have a package that's easier to understand and maintain (see #729242). Did you have the time to consider the list of the packages you'd like to have? My list has not changed: https://bugs.debian.org/692274#56 Let me know if you need more details. Thx for your work ! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692274:
Hi, I had planned to propose something similar by the begining of september (busy summer). I would propose: asciidoc-docbook - only the necessary stuffs to work with html backends (virtual package) asciidoc-dblatex - only the necessary packages to work with dblatex pdf generation (virtual package) asciidoc-fop - idem for fop pdf generation (virtual package) asciidoc-man - packages to generate man pages only (virtual package) asciidoc-full - with that you could do everything (virtual package) asciidoc-minimal - the lightest possible (virtual package) asciidoc - keep current requirements for now asciidoc-doc - Documentation and examples (so splitting the current package here) asciidoc-vim - vim files for asciidoc syntax (no more in the asciidoc base distribution) What do you think? Joseph -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692274:
On Thu, Jul 3, 2014 at 9:07 AM, Alexander Wirt formo...@debian.org wrote: On Thu, 03 Jul 2014, Mathieu Malaterre wrote: Neat suggestion: https://bugs.debian.org/692274#41 ! indeed. do you want to provide some suggestions for names and dependencys? Technically all backends would be defined (docbook45, xhtml11, html4, html5, slidy, wordpress or latex). With this defnition asciidoc-docbook45 would also pull in fop just in case target document type is PDF (fop is not required when doc type is article or manpage...but we are getting picky). The only one I would be interested (selfish) is asciidoc-docbook45 (offline docbook + pdf). Thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692274:
Neat suggestion: https://bugs.debian.org/692274#41 ! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692274:
On Thu, 03 Jul 2014, Mathieu Malaterre wrote: Neat suggestion: https://bugs.debian.org/692274#41 ! indeed. do you want to provide some suggestions for names and dependencys? Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692274: asciidoc: a2x uses xmllint by default internally, but does not depend on libxml2-utils
Package: asciidoc Version: 8.6.7-1 Severity: serious Justification: Policy 7.2 a2x internally uses xmllint by default. It can be disabled on the command line, but it is used by default. This yields to build failures in deterministic setups, where recommends are not installed by default, e.g. Debian buildds. I don't think recommending libxml2-utils is good enough, unless you make the absence of xmllint non fatal. That's a problem for example to packages build depending on asciidoc, but not on libxml2-utils when compiling manpages from source as required by policy 2.2.1. That would cause build failures like: a2x --doctype manpage --format manpage -D debian/man/ \ docs/man/some.man-page.man a2x: ERROR: xmllint --nonet --noout --valid /«PKGBUILDDIR»/debian/man/some.man-page.xml returned non-zero exit status 127 make[1]: *** [debian/man/some.man-page] Error 1 make[1]: Leaving directory `/«PKGBUILDDIR»' make: *** [binary] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2 -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.5-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages asciidoc depends on: ii python 2.7.3-2 Versions of packages asciidoc recommends: ii dblatex0.3.4-2 ii docbook-utils 0.6.14-3 ii libxml2-utils 2.8.0+dfsg1-5 ii xmlto 0.0.25-2 Versions of packages asciidoc suggests: pn source-highlight none ii vim-addon-manager 0.5.0 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692274: asciidoc: a2x uses xmllint by default internally, but does not depend on libxml2-utils
Same for xsltproc and docbook-xml, although the latter may arguably be a case for recommendations in libxml2-utils, because it is only required because a2x passes -nonet internally to xmllint (which is good). -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#692274: asciidoc: a2x uses xmllint by default internally, but does not depend on libxml2-utils
severity 692274 important thanks Arno Töll a...@debian.org wrote: Package: asciidoc Version: 8.6.7-1 Severity: serious Justification: Policy 7.2 a2x internally uses xmllint by default. It can be disabled on the command line, but it is used by default. This yields to build failures in deterministic setups, where recommends are not installed by default, e.g. Debian buildds. I don't think recommending libxml2-utils is good enough, unless you make the absence of xmllint non fatal. That's a problem for example to packages build depending on asciidoc, but not on libxml2-utils when compiling manpages from source as required by policy 2.2.1. That would cause build failures like: Such packages should be fixed to add the necessary build-dependency then. This issue is not RC, since the package lacks a hard dependency relation for an optional dependency. Things could be improved (as you duly noted) by changing the default, detecting available dependencies or adding recommends to the package but this still doesn't justify an RC severity. I'm lowering the severity to important. Best, -- Mehdi Dogguy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692274: asciidoc: a2x uses xmllint by default internally, but does not depend on libxml2-utils
tag 692274 wontfix severity 692274 normal thanks On Sun, 04 Nov 2012, Arno Töll wrote: Package: asciidoc Version: 8.6.7-1 Severity: serious Justification: Policy 7.2 a2x internally uses xmllint by default. It can be disabled on the command line, but it is used by default. This yields to build failures in deterministic setups, where recommends are not installed by default, e.g. Debian buildds. I don't think recommending libxml2-utils is good enough, unless you make the absence of xmllint non fatal. That's a problem for example to packages build depending on asciidoc, but not on libxml2-utils when compiling manpages from source as required by policy 2.2.1. That would cause build failures like: a2x supports several formats and I decided that all of them should be fullfilled only by recommends. If you want to use a2x you may have to adjust your build-deps. Afair asciidoc itself doesn't use xmllint, so the recommends is correct here. This change was done some time ago especially for those guys using asciidoc in build-depends. In the past all output formats of a2x were supported in Depends which led to an enormous dependency chain. Therefore I changed it, and I don't plan to revert the change. Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692274: asciidoc: a2x uses xmllint by default internally, but does not depend on libxml2-utils
On 04.11.2012 21:09, Alexander Wirt wrote: a2x supports several formats and I decided that all of them should be fullfilled only by recommends. If you want to use a2x you may have to adjust your build-deps. Afair asciidoc itself doesn't use xmllint, so the recommends is correct here. This change was done some time ago especially for those guys using asciidoc in build-depends. In the past all output formats of a2x were supported in Depends which led to an enormous dependency chain. Therefore I changed it, and I don't plan to revert the change. Well, but as it looks to me, this essentially means that /nobody/ can use asciidoc conversions as is because most/all depend on some third party package, without digging yourself what third party packages are used. This means that maintainers need knowledge of internal implementation details of asciidoc. That's an unfortunate situation and people need to debug the very same issues over and over, and find their own workarounds in their packages to it. I suppose the rationale is mostly that asciidoc otherwise has huge build dependencies. Why don't you provide some meta packages to depend on instead then? Let's call them asciidoc-man, asciidoc-latex and so on, and provide them in your source package. They can be empty and people could depend on asciidoc-man instead, which in turn would Depend: asciidoc, other-stuff-required-for-man-conversion That would make us all happy, and you could still keep the default in recommends for the asciidoc package itself. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
