On 23 February 2016 at 09:58, Jan Engelhardt
On Tuesday 2016-02-23 00:19, Terry Burton wrote:
Solution: Do not supply a DEBTRANSFORM-TAR line at all.
Thanks. I seem to recall that when DEBTRANSFORM-TAR is omitted debtransform croaks because it sees both _service:tar_scm:postscriptbarcode-{VERSION}.tar and_service:recompress:tar_scm:postscriptbarcode-{VERSION}.tar.gz as candidates for the tarfile. I will test this tomorrow as it's getting late.
The former will be deleted. At least that is what I can see from just looking at /srv/obs/sources/PKG.
You're right! Apologies for the noise with this. Not sure why my early builds had problems. I might step through the revisions to find what I did wrong.
You could just remove the debian/ directory from the source tarball. Many projects, so I believe, have done that over the last 15 years as they realized that distro-specific code should be with the distro instead, also because it has been a bitrot factor.
I agree that this is true for most standard packages especially if the authors do not care about packaging. BWIPP is an extensive resource programmed in an atypical programming language (PostScript) and uses custom compilation routines to prepare the resources in a number of formats.
What I gather from https://github.com/bwipp/postscriptbarcode/releases is that there appears to be no C source code, so the rest is data files which can be flung into an arbitrary directory that you just have to point ghostscript to.
The API for the C library and bindings are not currently finalised so I don't ship it in the release builds yet. The development code is here: https://github.com/bwipp/postscriptbarcode/tree/master/libs I don't want to presume on your interest so forgive me if the following is more information that you care to digest and not directly related to OBS packaging: BWIPP traditionally shipped tarballs containing the PS resources in a number of formats that work best in certain scenarios: a monolithic file, a set of split files with a resource descriptor, each in either "raw-PS" or "packaged" into a compressed form. BWIPP is used by a large number of open source software applications (Scribus, LaTeX, KBarcode, ...), libraries (Ruby GS, bwip-js, python-Elaphe, ...) and many more commercial applications including being embedding in printer hardware. Each project has tended to bundle some variant of the BWIPP PS (akin to a bundled library) and interface with it in a custom way, often embedding a lot of metadata about the capabilities of each barcode encoder within their application code. Obvious problems ensue. My plan to remedy with the C helper library and bindings which when finalised will be packaged consistently for major distributions. This will allow projects to interface consistently against a common library and no longer bundle the PS, provide quirky interfaces or embed lots of unnecessary code. Hence my interest in packaging since I think this will be important to the long-term maintainability of all of the products in the BWIPP ecosystem.
Iff there is something to actually build/compile, then, if a Makefile/configure/etc. thing is not sufficient generate it for the user, that Makefile (or lack thereof) should be revised.
Sorry if I have been misleading. The build process for the PS resources and bindings can in fact be driven by make, but packaging a number of modules for different languages requires learning a number of different packaging conventions as can be seen from this spec file: https://raw.githubusercontent.com/bwipp/postscriptbarcode/master/open-build-... So my aim with providing upstream packaging files is to do the initial hard work which others can improve on. OBS just makes this just a little more difficult that seems necessary (separately enumerating each debian.* file) but not as awkward as I feared. Thanks again as you've been a great help. All the best, Terry -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org