David Anderson writes ("Re: Packaging a library that requires cross-compiled
code"):
> This provides a way to build the entire package, using only
> debian-provided packages, with a 'caching' functionality to avoid
> having to rebuild a toolchain if a previous version of the package is
> installed.
I saw you were having some trouble with that. I'm afraid I can't
offer much beyond sympathy. It's unfortunate, but you're just
tackling a difficult problem.
As an alternative to the difficulties you have right now, one way
perhaps would be to ship the source package containing both the source
(including cross-compiler) so that it builds the binary fragment, but
also contains it, and provide an easy way to allow the user to reuse
the provided one without building the compiler.
> One case that I feel is missing from this setup is the trivial "just
> use the blob provided by upstream". Given that we now have the entire
> machinery to rebuild the blob if someone really really wants to (as an
> aside, I'd like to repeat that the only thing I can see anyone doing
> with it is either breaking the flashing process, or damaging the brick
> by messing with the flash write timing), would it be acceptable to
> default to using the upstream blob, unless an explicit force flag is
> passed to debian/rules ?
A better approach would be to compare the built binary blob and die if
it's not identical to the upstream one. Obviously there would be some
kind of override - easiest perhaps just to remove the existing binary
blob.
That means that any accidental breakage to the building machinery will
be spotted and fixed, but users are still able to change it. You'd
want to leave a comment in the source file warning someone who edits
it that they have to hit the check over the head as well.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
