• With a Git Repository
    		•

    Kali Linux Revealed




    Download 11,68 Mb.
    Pdf ko'rish
    bet136/174
    Sana15.01.2024
    Hajmi11,68 Mb.
    #137314
    1   ...   132   133   134   135   136   137   138   139   ...   174
    Bog'liq
    Kali-Linux-Revealed-2021-edition

    Quilt Patch Series
    This patch management convention has been popularized by a tool named
    quilt
    and the “3.0 (quilt)” source package format is thus compatible with this tool—with
    the small deviation that it uses
    debian/patches
    instead of
    patches
    . This tool is
    available in the package of the same name and you can find a nice tutorial here:
    è
    https://raphaelhertzog.com/2012/08/08/
    how-to-use-quilt-to-manage-patches-in-debian-packages/
    If the source package uses the 1.0 or 3.0 (native) source format, then there is no requirement to
    register your upstream changes in a patch. They are automatically bundled in the resulting source
    package.
    With a Git Repository If you have used Git to retrieve the source package, the situation is even
    more complicated. There are multiple Git workflows and associated tools, and obviously not all
    Debian packages are using the same workflows and tools. The distinction already explained about
    source format is still relevant but you must also check whether patches are pre-applied in the
    source tree or whether they are only stored in
    debian/patches
    (in this case, they are then applied
    at build time).
    The most popular tool is git-buildpackage. It is what we use to manage all repositories on git-
    lab.com/kalilinux/packages. When you use it, patches are not pre-applied in the source tree but
    they are stored in
    debian/patches
    . You can manually add patches in that directory and list them
    in
    debian/patches/series
    but users of git-buildpackage tend to use
    gbp pq
    to edit the entire
    patch series as a single branch that you can extend or rebase to your liking. Check the manual
    pages for
    gbp-pq(1)
    to learn how to invoke it.
    git-dpm (with associated command of the same name) is another git packaging tool that you can
    find in use. It records metadata in
    debian/.git-dpm
    and keeps patches applied in the source tree
    by merging a constantly-rebased branch that it builds out of the content of
    debian/patches
    .
    Tweaking Build Options
    You usually have to tweak build options when you want to enable an optional feature or behavior
    that is not activated in the official package, or when you want to customize parameters that are
    set at build time through a
    ./configure
    option or through variables set in the build environment.
    In those cases, the changes are usually limited to
    debian/rules
    , which drives the steps in the
    package build process. In the simplest cases, the lines concerning the initial configuration (./con-
    figure …) or the actual build ($(MAKE) … or make …) are easy to spot. If these commands are not
    234
    Kali Linux Revealed

    explicitly called, they are probably a side effect of another explicit command, in which case, please
    refer to their documentation to learn more about how to change the default behavior. With pack-
    ages using
    dh
    , you might need to add an override for the
    dh_auto_configure
    or
    dh_auto_build
    commands (see their respective manual pages for explanations on how to achieve this).
    To make those explanations more concrete, let’s apply them to our sample use case. You decided
    to modify libfreefare to pass the --enable-debug option to the
    ./configure
    script so that you
    could get a more verbose output from your near field communication (NFC) tools and file a better
    bug report about your non-recognized Mifare NFC card. Since the package uses
    dh
    to drive the
    build process, you add (or in this case modify) the override_dh_auto_configure target. Here is the
    corresponding extract of libfreefare’s
    debian/rules
    file:
    override_dh_auto_configure:
    dh_auto_configure -- --without-cutter --disable-silent-rules --enable-debug
    Packaging a New Upstream Version
    Let’s take a look at an example at this point, as we discuss packaging upstream versions. Let’s say
    you are a SET power-user and you noticed a new upstream release (7.4.5) that is not yet available
    in Kali (which only has version 7.4.4). You want to build an updated package and try it out. This is a
    minor version bump and you thus don’t expect the update to require any change at the packaging
    level.
    To update the source package, you extract the new source tarball next to the current source pack-
    age and you copy the
    debian
    directory from the current source package to the new one. Then
    you bump the version in
    debian/changelog
    .
    $ apt source set
    Reading package lists... Done
    NOTICE: ’set’ packaging is maintained in the ’Git’ version control system at:
    https://gitlab.com/kalilinux/packages/set.git
    Please use:
    git clone https://gitlab.com/kalilinux/packages/set.git
    to retrieve the latest (possibly unreleased) updates to the package.
    Need to get 42.3 MB of source archives.
    [...]
    dpkg-source: warning: failed to verify signature on ./set_7.4.4-0kali1.dsc
    dpkg-source: info: extracting set in set-7.4.4
    dpkg-source: info: unpacking set_7.4.4.orig.tar.gz
    dpkg-source: info: unpacking set_7.4.4-0kali1.debian.tar.xz
    dpkg-source: info: applying edit-config-file
    dpkg-source: info: applying fix-path-interpreter.patch
    $ wget https://github.com/trustedsec/social-engineer-toolkit/archive/7.4.5.tar.gz -O
    å

    Download 11,68 Mb.
    1   ...   132   133   134   135   136   137   138   139   ...   174




    Download 11,68 Mb.
    Pdf ko'rish