Hi, Am Donnerstag, dem 17.02.2022 um 03:06 -0500 schrieb Philip McGrath: > Hi, > > On 2/17/22 02:10, Liliana Marie Prikler wrote: > > [...] > > I was picturing something like > > > > (define chez-bootfiles (chez ...) > >    (package/inherit chez > >      (inputs ...) > >      (native-inputs ...) > >      (build-system ...) > >      (arguments ...))) > > > > Sorry, I still don't think I'm following. Would this rely on the > `mative-inputs` being thunked to let the result of this function be > an input to `chez-scheme`?  Yes. > What commonality is the function abstracting over, compared to having > 'chez-scheme-for-racket-bootstrap-bootfiles' inherit from 'chez- > scheme-bootstrap-bootfiles'? At the moment version, source, home-page and license. I don't really think bootstrap files ought to be a part of chez' source, so if you wanted to do this really cleanly, you'd have to drop them from chez and add restrict chez-bootstrap to them, which would imply you'd have to use (version (package-version chez-scheme)) explicitly – for now I don't want to add too much burden to that patch and you can assume source to be the same between the two. > (I'm using "-bootstrap-bootfiles" because there are also other kinds > of bootfiles: applications can create their own bootfiles, e.g. > "racket.boot", and using Chez as a cross-compiler also involves more > bootfiles.) I have no idea how useful that feature is or how widely it is used, but if those are just binary blobs needed to get chez scheme running, we ought to treat them as that. That makes some sense with respect to the license and home page, but > > > That makes some sense with respect to the license and home page, but > what about 'package-source' and 'package-version'? Your patch currently makes them the same for both, so you tell me :P See above for long-term plans. Cheers