Niels Thykier <ni...@thykier.net> writes: >> A complication is that each platform config package installs the same >> set of files, so the normal package build technique of having all files >> being installed to a common staging directory and each package's files >> being selected by the debian/<package>.install doesn't work. >> > > Not quite sure I understand exactly what the issue is, so I might miss > with this.
A quick, cut-down, example: There are a set of configuration files for each (hardware) platform. We generate a separate platform specific package for each, but each package will contain the same files (but different file contents). For this example, assume that there are only two platforms: "x1000" and "x2000". Thus we need to create "opx-platform-config-x1000" and "opx-platform-config-x2000" packages. Each of those packages will contain the config file /etc/opx/foo.xml. > Are you aware that debian/<pkg>.install can be made executable and thus > arbitrary filter based on any logic you can devise in said file? Now that you mention it, I do recall reading this before. And now that I've refreshed my memory by reading (https://www.debian.org/doc/manuals/maint-guide/dother.en.html#install), I see that *.install files can specify both the source and destination paths. So maybe I can forgo configure/make/install entirely and have each debian/<pkg>.install file copy files directly from the sources. > The only two uses in Debian, I know of, rely on the selection being done > /before/ the build starts. Not quite sure how they well they fit you, > but they are: > > * Generating debian/control from debian/control.in > * Using Build-Profiles to omit building some packages (using a > "pkg.${sourcepkg}.${name_of_choice}" profile[1]). > > [1] https://wiki.debian.org/BuildProfileSpec > > It is primarily targeted as dealing with dependencies bootstrapping > issues, but it does list an "Extension namespace". Thanks Niels, I'll follow up on these as well. --jtc