Mailinglist Archive: opensuse-buildservice (138 mails)

< Previous Next >
Re: [opensuse-buildservice] Improvements for building .deb packages for projects with an in-tree debian/ (or debian.upstream/) directory
On 23 February 2016 at 09:58, Jan Engelhardt <jengelh@xxxxxxx> wrote:
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-service/postscriptbarcode.spec

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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-buildservice+owner@xxxxxxxxxxxx

< Previous Next >