Seeking recommendations wrt. target-specific packages
I tried asking this on the deity list and didn't get any bites, I'm
hoping I'll have better luck with mentors.
At my workplace, our product is built from several dozen target-
independent packages, with a small number of target-specific packages.
I use the word "target" instead of platform as our (current) hardware
has a common OS (Debian-jessie) and CPU architecture (amd64); but
there are other hardware-specific differences that are handled by
the target-specific packages (config files, user space drivers, etc.).
We are planning on open sourcing and providing a binary repository for
many of these packages in the next month or so; and I would like to
deliver something that "makes sense" to Debian users/administrators.
At some point in the future, if the open source project takes off, it
may make sense for these components to be part of Debian itself. I
really appreciate any guidance and assistance you can offer.
We currently implement this by having target-independent packages
depend on a virtual package, which is provided by target-specific
packages that implement that virtual package interface. (FWIW, we
used virtual packages instead of "or" dependencies so the
target-independent packages don't have to be re-spun with new
dependencies when new target-specific packages are created as new
hardware devices is developed).
For example, a given target-independent package might "depend" on a
"xx-target-config" virtual package. The concrete implementation of the
"xx-target-config" interface for target foo would be "provided" by
package "xx-target-config-foo".
For the most part, this works well. Although we do have a unsolved
issue due to the ambiguity when there are more than one concrete
implementations in a package repository. This means we can't simply
install high-level application packages and have apt-get resolve all
their dependencies automatically, as the packages for the specific
target may not be selected.
I've read the policy manual and couldn't find any guidelines that
address this use case.
My proposed solution for this is to create target-specific package
repositories (with different "distributions" or "components"). The
configuration on a target would then have two entries, one for the
target-specific packages, another for target-independent packages.
For example, something like:
deb http://apt.example.com unstable main
deb http://apt.example.com unstable main-foo
Or:
deb http://apt.example.com unstable main
deb http://apt.example.com unstable-foo main
(we follow the unstable, testing, release, etc. pattern set by Debian
itself).
Before I go ahead with this, I'd appreciate some feedback on this
approach. Should we plan to use "distribution" or "component" for
target-specific packages. Or are we completely off track and we
should be considering an entirely different approach?
Thanks in advance,
--jtc
Reply to: