Re: Seeking recommendations wrt. target-specific packages
jtc@acorntoolworks.com (J.T. Conklin) writes:
I'll give this one more try.
We're planning on open sourcing and providing a binary repository for
these packages this month. I'd really like to deliver something that
"makes sense" to Debian users/administrators.
--jtc
> 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.
>
> [..snip..]
Reply to: