3

I am building and distributing my code as a deb package (built with cmake, packaged with CpackDeb) to a Ubuntucore-based 16.04 LTS. The package installs a config file among else. I can't get apt/apt-get to keep the old configuration file during an update. It silently overrides the old config in all test cases and regardless of whether it had been edited or not. Things I tried:

$ apt-get -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" install <package>

$ export DEBIAN_FRONTEND=noninteractive ; apt-get install -y -o Dpkg::Options::="--force-confold" <package>

And some variations. The result is always the same - a silent override of the old config file. apt version is 1.2.31, I am on an arm64 processor.

Maybe I am not packaging the deb correctly? My config file is simply an installable. I'm not aware of any special requirements for config files, are there any?

2
  • Where is your config file installed? Are you using debhelper to build your package? Commented Apr 11, 2019 at 9:30
  • I am using Cmake's CPackDeb. Installed to /etc/<foo>/
    – user907323
    Commented Apr 11, 2019 at 9:42

1 Answer 1

4

You need to include a conffiles file in your control control.tar.gz. When creating a package with dpkg-deb this is placed in DEBIAN/conffiles. This file should have exactly one line for every config file contained in your debian package. Each line specifies the full path of a config file.

See https://manpages.debian.org/testing/dpkg-dev/deb-conffiles.5.en.html

The result of including this will be that these files are registered on the system as config files and will not be automatically overwritten.


I've not used CPackDeb myself, but there's a reference for how to add files to control.tar.gz here:

https://cmake.org/cmake/help/v3.0/module/CPackDeb.html?highlight=conffiles

set(CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA
    "${CMAKE_CURRENT_SOURCE_DIR/prerm;${CMAKE_CURRENT_SOURCE_DIR}/postrm") 
5
  • ... assuming you're using dh_installdeb which I've never bothered to. But okay I'll edit Commented Apr 11, 2019 at 9:39
  • 1
    You’re making a few assumptions which are liable to confuse readers. If building from source, you hardly ever manipulate DEBIAN directly. If you write a conffiles in your control directory, it won’t be taken into account in debhelper compatibility level 12 or later. Of course if you don’t use debhelper then you need to deal with things yourself but that’s not what I’d expect new packagers to do... Commented Apr 11, 2019 at 9:41
  • Aha, so I am indeed not packaging correctly. Any idea how to achieve that behavior with CPack? Will look into CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA.
    – user907323
    Commented Apr 11, 2019 at 9:43
  • I can see the ambiguity with debhelper's nomenclature. I've edited to quantify the use of the DEBIAN directory for dpkg-deb although I note a conffiles file for installation into DEBIAN is also correct for debhelper where it does not automatically find config files. The underlying file format doesn't use the name DEBIAN and I was unaware of any name collisions with other packaging utilities. Commented Apr 11, 2019 at 10:14
  • @Philip thanks, your answer seems OK to me now. The assumptions I was referring to were that (1) that users were building binary packages directly, using dpkg-deb (which you’ve made explicit) and (2) that conffiles is a universal solution — as mentioned above, in the current compatibility level (12), debhelper will ignore any conffiles provided in the packaging. Commented Apr 11, 2019 at 11:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .