4

Recently after performing an upgrade, and hence having to redo some of the manual configuration changes I'd performed, e.g. to configs in /etc or /usr/share, I decided I'd be more strict with myself this time and put all changes I make to my system into packages, so on the next upgrade I can just install my packages and have everything ready to go.

My first package is for my custom keymap. Following this post: create a .deb Package from scripts or binaries I have created a folder for the package and have my keymap listed in the debian/install file, to be installed in /usr/share/X11/xkb/symbols. I'm also going to need to add the symbols to /usr/share/X11/xkb/evdev.xml for them to be recognised, and thought that it would be better to use patch for this rather than overwriting the file.

To reiterate, I want to use patch as the installation method for my alterations to evdev.xml, not to patch package source code using quilt (which is what I've found through Internet searching)

So I have my keymap in the install file, and a patch command in the postinst file. My problem is that I don't know how to include the patch files into the package; after running debuild, the script and keymap are in the deb file, but the diffs aren't, so the postinst script won't be able to run.

Is there a way I can get my patches (or better, a folder called Patches) into the package, for use during the installatoin? If possible, I don't want to install these patches anywhere as they're only necessary during the installation process.

Thanks.

3 Answers3

1

I enhanced the firmware-b43-installer package to include b43-fwcutter, my wifi driver, the wireless network name, and password. After installing this improved package, whether in a new installation or live session, I can directly access the Internet.

Befor this modification, the firmware-b43-installer package requires an Internet connection to download the b43 wifi diver file in a compressed form from its source. It also requires a package to unzip this compressed file and b43-fwcutter package to install the driver.

After the original package is extracted, I include /usr/bin/b43-fwcutter, /tmp/broadcom-wl-6.30.163.46.wl_apsta.o (wifi driver), and /tmp/90-NM-78089ae7-44f7-4655-890e-439c8688f671.yaml (the netplan) to the main directory that extracted from the deb file. The meaning is in the installation process, these files will be placed in these places.

The control (in the Depends line) and postinst files were edited to avoid downloading files or installing additional packages. in addition, the postinst file was edited to play some commands required to install the driver, generate, and apply the netplan. the original directory extracted from the deb file was renamed my-firmware-b43-installer. the new postinst file looks like this:

#!/bin/sh
set -e

. /usr/share/debconf/confmodule

b43-fwcutter -w /lib/firmware /tmp/*wl_apsta.o #install the firmware modprobe -r b43 bcma #block other driver
modprobe -r brcmsmac bcma #block another driver modprobe b43 #activate my drive cp /tmp/90-NM-78089ae7-44f7-4655-890e-439c8688f671.yaml /etc/netplan/90-NM-78089ae7-44f7-4655-890e-439c8688f671.yaml #copy my netplan netplan apply #apply my netplan

After that, this command was applied to make the deb file:

dpkg-deb  --build my-firmware-b43-installer
Talaat Etman
  • 1,340
0

If you create patch scripts that get applied using debian maintainer scripts then you still need a repository to hold the packages and a command to install it from.

Instead I'd go for an Ansible playbook.

  • It is easier to create and maintain
  • It can be applied to many computers with same effort
  • It can be adapted quite easily for different OS (versions and flavors)

See https://docs.ansible.com/ansible/latest/getting_started/introduction.html?extIdCarryOver=true&sc_cid=701f2000001OH6uAAG

queeg
  • 265
0

Short of installing them somewhere like /usr/share/$package/patches/, there isn't a way that I know of to have those files available during the postinst script's run. More importantly, while this is a package just for your use, it is bad practice for one package to change files owned by another package. It also means that your changes will just get blown away when the other package gets updated. You'd be much better using dpkg-divert. See also this question.