[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian packaging for packages that provide the same files



Niels Thykier <niels@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


Reply to: