0

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?

Seamus
  • 2,522
  • 1
  • 16
  • 31

1 Answers1

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.

Stephen Kitt
  • 411,918
  • 54
  • 1,065
  • 1,164
  • 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 '22 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. – Stephen Kitt Apr 21 '22 at 21:09
  • Thanks again for this - the answer I needed for now. I found this [interesting article](https://www.eyrie.org/~eagle/notes/debian/git.html) 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 '22 at 18:22
  • I've done more research, but still have a question wrt your stmt: `... as long as they can also retrieve the corresponding .orig tarball`. AIUI, the `.orig tarball` is just the *pristine upstream sources* from the author's (Roy Marples') repo, and is included not because it's used in the build process, but as a *comparative recourse* (?). If so, then am I "in bounds" wrt Debian Policy providing a decompressed tarball in a separate branch in my repo? I'd prefer to avoid hanging a tarball in the GitHub repo. I can make this a new question if you prefer? – Seamus Apr 23 '22 at 05:49
  • 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. – Stephen Kitt Apr 23 '22 at 07: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). – Stephen Kitt Apr 23 '22 at 07:49
  • Still plodding slowly ahead :) I think I like the `pristine-tar` & `git build-package` suggestions (though the docs confused me wrt [`gbp-buildpackage` vs `git-buildpackage` (which I installed)](https://manpages.debian.org/bullseye/git-buildpackage/gbp-buildpackage.1.en.html). Anyway - Does this mean I need to create a branch in my git repo named `pristine-tar` to use the `git(gbp?)-buildpackage`, and can I simply source that `pristine-tar` branch from the `*orig.tar.xz` tarball? – Seamus Apr 26 '22 at 07:36