For a little something I made (that used to be a word-of-mouth thing only and that's interesting to just a very narrow, and usually non-technical, user base), I'd like to be able to provide a .deb file for easier installation.

The something doesn't have any actual files that it needs to install in the system. Instead it needs to add some lines to already existing files (which belong to the xkb-data package on Debian-derived distributions). To the best of my knowledge, after searching and asking around, there's no way to put these lines into new, separate files and still have them be picked up by the system, so I wrote a Rakefile to do the installation. That works well but requires the user to interact with a command-line, which doesn't always work so well. Also, whenever xkb-data gets updated through the package manager, the rake task needs to be ran again manually, which is cumbersome.

I know about DpkgPostpone and DpkgTriggers, but none of these seem to be intended or fit for dealing with the above described problem (please do correct me if I'm wrong about that, though!)

Is there any way to have a Debian package automatically cause its own reinstall based on the condition that one or all of its dependencies have just been updated? I'm explicitly also interested in a hackish way to do so, DontBreakDebian be damned.

  • It is not clear what was already tried and how can we assist into complementing that. The question is too broad as it is. I would advise seeing our FAQ. – Rui F Ribeiro Jun 17 at 10:41
  • I googled with various search words, asked on irc.freenode.net#debian (where people said it might be possible, but they don't know how), read the two Wiki pages about Postpone and Triggers that are linked in the question and then ran out of ideas. Hence the question here. Do you have any concrete suggestions as to how it could be improved? – sixtyfive Jun 17 at 11:08

One reasonable way of going about this is as follows:

  • divert all the files you modify, so that dpkg no longer replaces them, but instead installs them with a different name;
  • make your Rakefile do its work using the newly-named files instead of the originals, reading the newly-named files and writing the originals;
  • install a post-invoke dpkg hook in /etc/dpkg/dpkg.cfg.d which runs the Rakefile after dpkg runs.

You could add additional checks, for example only run the Rakefile if the checksums of the original files have changed since the last time the modified files were generated, but that might not save much time compared to running the Rakefile every time dpkg runs, and adds a fair amount of maintenance complexity. (I wrote this assuming that your Rakefile behaved like a Makefile, i.e. didn’t do anything if its targets were newer that their prerequisites, but I get the impression that that isn’t the case here, so it’s probably more relevant to add additional checks or alter your Rakefile to not do anything if there’s nothing to do. Or you could rewrite your processing in a Makefile instead.)

I imagine you’ve already thought of this, but I think the ideal solution would be to add a new keyboard type instead of changing existing keyboard definitions; but there could well be some issue with this that I haven’t thought of.

  • Genius, thank you Stephen! (Yes, the Rakefile doesn't work like a Makefile and I don't much feel like rewriting it into a Makefile, either. It does do some checks of its own though and it won't be a problem to adapt it to work in the way you describe.) – sixtyfive Jun 17 at 15:51

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.