On 22 February 2016 at 22:27, Jan Engelhardt
On Monday 2016-02-22 22:51, Terry Burton wrote:
1. SUPERFLUOUS TAR FILE: I'm using tar_scm to create the tarball from the project's Git repository and to provide automatic versioning, however I seem to require a duplicate tarball just for DEB that has a static filename as referenced from the DEBTRANSFORM-TAR tag. It would be great to be able to simply use the versioned output of tar_scm (recompressed).
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.
2. DEBIAN.* FILES: I have to separately map each of the files in my project's debian.upstream/ directory to debian.* files for OBS. It would be great to indicate to debtransforn that a particular directory in the tarball contains Debian packaging. [ 2a. [...] Debian guidance is for upstream projects to name any included DEB packaging something other than debian/ such as debian.upstream/ as I now do. So indicating that some otherwise-named directory provides the DEB packaging seems preferable. ]
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. Beyond this it also has a basic C helper library with bindings for several languages. Experienced packagers have struggled to get the build procedure right because they are so unfamiliar with the PostScript environment and they tend to pick a subset of the bindings that they are most familiar with and package only those leading to the wrong kind of diversity. Providing some guideline packaging that sets a firm standard and works well helps to promote consistency across distributions, even if they choose to trim the fat or specialise things. They have a benchmark against which to compare their own packaging and a neutral place to contribute improvements that might be useful for other distributions (or at least I can cherry-pick them). Continuous Integration of the packaging routines using services such as OBS helps to prevent bit rot (assuming the authors care about failures).
3. VERSIONING: A Debian non-native package must have a version that ends in "-N", which is incompatible with RPM versioning.
DEBTRANSFORM-RELEASE: 1
is necessary in the .dsc to get the automated "N" like it already happens for .spec builds.
This works. Very helpful, thanks! -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org