2

I try to customize and rebuild a Debian source package by adding some additional source files (not included in the upstream archive) and applying some patches. More specifically, I try to customize Ubuntu "ppp" package by adding a custom plugin. I do the following:

1) I download and unpack source package with "apt-get source ppp"

2) I go into "ppp-x.x.x" subtree and rebuild the package cleanly with "dpkg-buildpackage -uc" to make sure that everything is ok with the source package. (And actually everything is ok for now).

3) Now I take my custom patches and place them into "debian/patches" subfolder of the "debian" subtree. Then I reference them in "debian/patches/series" file. I also take my custom source files, all in a single folder, say "tacacs", and place this folder into the "debian/extra" subfolder. I am not sure that I should place them exactly there but I don't see any more suitable place for them.

4) Now I try to run "dpkg-buildpackage -uc" again to build a custom package. And I see the following:

  • "dpkg-buildpackage/dpkg-source/quilt" tries to apply my custom patches to my custom sources and cannot find them. So it fails and the build fails altogether.
  • After the build fails and stops I can see my custom plugin ("tacacs") subfolder in the build tree but it is empty. So it is not surprise that patch failed.

So the question is: where should I place my custom source files and what else should I do to make "dpkg-source -b" see them and inject them to the build tree?

Dmitriy Stepanenko
  • 51
  • 3
  • IIRC you need to enumerate them in `debian/files` or some such. – tripleee Mar 23 '17 at 06:21
  • @tripleee Thank you, but I believe you are wrong about `debian/files` in the exact sense. As I see this file contains the list of the output files generated in the build. There are a lot of other files containing the lists in the `debian` directory and perhaps I will have to try them all I do not get a correct answer before. – Dmitriy Stepanenko Mar 23 '17 at 13:48
  • Maybe I'm mixing it with `debian/install`. Quick googling suggests that this is where you enumerate nonstandard files you want to have installed somewhere. – tripleee Mar 23 '17 at 13:51

1 Answers1

2

I found two ways to solve my problem:

  1. The first one seems to be more proper and idiomatic. It is to place additional sources to "the supplementary original tarball" named after the main original tarball with addition of the "component name" (as described in man dpkg-source). Supplementary tarballs are extracted over the main tarball before the build and additional code gets to the build tree where it can be patched and compiled. In fact my additional code was already packed to the archive, so I just had to rename the archive.

    Unfortunately this method did not work for me, since the code from supplementary tarballs can be injected to the root of the build tree only, and pppd plugin code should be placed to the pppd/plugins subdirectory. And I could not find a way to create a symlink to the code in the proper subdirectory with dpkg-source/quilt.

  2. So I had to use the second method:

    • I unpacked additional source code directly to the proper place in the clean source tree created with dpkg-source -x (or apt-get source)
    • Then I applied dpkg-source --commit to the source directory and got a patch in the debian/patches subdirectory along with a proper series file referencing the newly-created patch. This patch contains all the changes that have occurred when additional sources were placed to the source tree. So the additional sources can be recreated in the proper place by reapplying this patch.
    • I saved the newly-created patch and the series file to the temporary location and deleted the source tree.
    • I recreated the clean source tree with dpkg-source -x.
    • I placed the saved patch and series file to the debian/patches folder of the source tree again. I also edited debian\changelog and debian\control to indicate that the new version of the package should be build and not mess the new package with the original one.

    • Now I could build a new version of the package with dpkg-buildpackage -uc -us. This was not a final version yet, since it did not contain my custom patches, but it did already contain my custom sources.

    • At last I added my custom patches to the debian/patches directory, added references to them to the debian/patches/series file, ran dpkg-buildpackage once more and got the package I wanted to get.

Though this method works with the source code injections to any desired place in the source tree, it has a drawback that additional sources should be unpacked manually, mixed with the original code and converted to the patch. All this manipulations have to be repeated each time this additional code is renewed. Whereas in the first method it is enough to replace the supplementary tarball with its new version and to make sure that all the subsequent patches apply well.

Dmitriy Stepanenko
  • 51
  • 3