Perhaps a dumb question, but I am new at this - so please bear with me.

Here is a brief description of the situation:

  1. I recently learned of a significant, long-standing bug in dhcpcd - the default network manager for RPi OS. Coincidentally, someone submitted a pull request to the dhcpcd GitHub site that was committed recently.

  2. The RPi organization does not publish their dhcpcd sources on GitHub, but they are available via apt-get source dhcpcd5. This yielded a new folder (~/dhcpcd5-8.1.2), a .dsc file (with several inaccuracies), and a compressed tar file (dhcpcd5_8.1.2.orig.tar.xz) - there was no diff.gz file/folder. I have incorporated the simple source code correction (one single line of code), and learned enough to successfully build a new .deb file. I have installed and tested the .deb file on 3 of my systems; it resolves the issue & I've found no side-effects

  3. I've advised an individual in the RPi organization of my findings some time ago, but have gotten no feedback. Apparently there is no venue for submitting user-proposed changes to the Debian package source files - no pull request mechanism iow.

I'd like to share my effort. It has occurred to me that there may (should?) be a method whereby I can effectively create a git repo from the contents of the Debian package dhcpcd source files. I know enough git to upload the contents of ~/dhcpcd5-8.1.2 into a GitHub repo; but my questions are these:

  1. The folder ~/dhcpcd5-8.1.2 contains some binary files. I think those files were created during the debuild process. How do I purge binaries from the sources in ~/dhcpcd5-8.1.2?

  2. There are several patches in dhcpcd5-8.1.2/debian/patches; can I safely rely on these answers from 2016 to ensure all the patches are applied to the source code?

  3. As I don't know enough to ask any further questions, I'll ask instead: "Will this work?" Meaning that if all the binaries are removed, and the current change & all previous patches are applied -- will someone with no specific expertise be able to clone the GitHub repo I want to create, and build it using debuild -b -uc -us?

1 Answer 1

  1. To clean a Debian package, i.e. remove all generated files and restore the source to its initial state, run

    fakeroot debian/rules clean
  2. dhcpcd5 is a “3.0 (quilt)”-format package, so extracting it with apt source etc. will extract it and apply any patches. You can further make sure of this by running

    quilt push -a
  3. If what you have locally builds with debuild, then yes, pushing your repository as-is will produce something that others can build, as long as they can also retrieve the corresponding .orig tarball. Note that your repository should contain the sources with patches unapplied, i.e. you should run

    quilt pop -a

    before committing your changes and pushing the repository.

There is a Debian git repository for dhcpcd5, but it hasn’t been maintained for a long time and is probably irrelevant here.

  • This is exactly what I was looking for :) I'll try it asap & follow up, but just for clarification on quilt and the patches: quilt pop a removes all listed patches from the code in src - is that correct? If so, I guess the quilt pop a simply clears the deck for the patches to be re-applied during debuild after the repo is cloned on a user's machine?
    – Seamus
    Apr 21 at 21:03
  • Yes, that’s right. When patches are applied, there’s matching state maintained in a .pc directory. That isn’t supposed to be shared, and without it, quilt, debuild etc. get thoroughly confused if the patches are already applied. That’s why a cloned repo should come with the patches unapplied. Apr 21 at 21:09
  • Thanks again for this - the answer I needed for now. I found this interesting article that shines light on some of the complexities in "building the bridge" between Debian's approach to packaging and distributing apps and git. Interesting stuff; looking forward to the merger.
    – Seamus
    Apr 22 at 18:22
  • 1
    The issue with the .orig tarball (as you say, the pristine upstream tarball in most cases) is that it needs to be present during the build to produce some of the upload artifacts, and it has to be identical to the tarball already in the repositories. You don’t have to host it yourself, if you track the version in Raspberry Pi OS then apt source will retrieve the right one. Another option is to store in using pristine-tar; git build-package can then extract it automatically as needed. Apr 23 at 7:46
  • 1
    All that said, the “correctness” of the .orig tarball only matters for packages which are intended for upload to an existing repository (Debian, Ubuntu, Raspberry Pi OS…). For a package intended for local builds only, it doesn’t matter; you only need to tell people where to download the upstream tarball (which can be as easy as uscan --force-download if debian/watch is accurate). Apr 23 at 7:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.