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
