Recent disappearance of asdf:bundle-system.

[Jason Miller]

On 11:43 Sun 16 Oct     , Faré wrote:
> >> So BUNDLE-SYSTEM has been restored, but the comment about its
> >> deprecation suggests that we should revisit its arglist to make it
> >> useful, if we are not going to remove it.
> >>
> My "no-operation-initargs" branch, that you (Robert) agreed to merge
> after the next release, does away with bundle-system.
> 
> >> The function is not documented, and reading the code doesn't help me (as
> >> someone who doesn't routinely use bundle ops): it defers to
> >> DELIVER-ASD-OP, but that operation is documented as:
> >>
> >> "produce an asd file for delivering the system as a single fasl"
> >>
> >> which suggests that it makes a .asd file, and doesn't bundle anything at
> >> all.
> >>
> It uses compile-bundle-op (née fasl-op) to create a single .fasl for
> the entire system,
> then also creates a .asd file that will load that .fasl file. But
> there is no good place to store that .asd file least it overwrites the
> source .asd file, and no good place to store the .fasl file besides
> the per-implementation fasl cache. The whole interface is lacking, and
> is not directly usable as is, though it isn't too hard for users to
> write a wrapper that copy or redirect the output where they want it to
> be, using deliver-asd-op directly and querying asdf:output-files.
> Thus, the function has no purpose and should be removed.

I currently use compile-bundle-op and deliver-asd-op (in fact expect a
bugfix soon) for creating read-only loadable systems for Nix (I
previously tried just managing the output translations but found it to
get too hairy; with the bundles no changes to the output translations
are necessary).

Are these two operations here to stay?

-Jason