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

Seeking recommendations wrt. target-specific packages



I recognize that this may be a bit off-topic for the deity list. If
there's a more appropriate forum, I apologize for the intrusion and
ask to be pointed in the right direction.

At my workplace, our product is built from several dozen platform
independent packages, with target-specific packages that provide
target-specific implementations. All our targets have a common OS and
CPU architecture; what I mean by "target" is a specific hardware
device.

We implement this by having the platform-independent packages depend
on a virtual package, which is provided by target-specific packages
that implement that virtual package interface.  We used virtual
packages instead of "or" dependencies so the platform-independent 
packages don't have to be re-spun with new dependencies when new
target packages are created.

For example, a given platform-independent package might "depend" on a
"xx-platform-config" virtual package. The concrete implementation of
the "xx-platform-config" interface for target foo would be "provided"
by package "xx-platform-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 platform- 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: