Hi, Quoting Helmut Grohne (2016-02-02 22:55:02) > By now, rebootstrap[1] is a heavy user of dose-builddebcheck and invoking it > well over 50 times per run. This starts to manifest in the time it takes to > run rebootstrap. Thus far I am always passing the same set of build profiles > to dose, but in future I would like to ask it for building some packages with > different profiles than others. Of course, I can simply run > dose-builddebcheck for each profile combination, but each of those > invocations incurs the parsing of Packages and Sources and thus increases the > time to run rebootstrap. > > For example, I would like to be able to ask dose-builddebcheck whether > util-linux can be built under stage1 or tar can be built with no > profiles. > > Johannes suggested splitting the parsing phase into a separate step, > such that multiple queries could be made against the same Packages file > without incurring the cost of parsing multiple times. more precisely, I see two problems with implementing the original proposal in practice: a) how to implement the user interface so that the user is able to pass package specific profiles b) the information somehow has to be handed down all the way to the Sources parser, touching lots of code in the process as a way to solve a), Helmut suggested the following command line format: --profiles stage1 --check-only util-linux --profiles "" --check-only tar Unfortunately it seems that this won't fly with dose3's current command line parser (OptParse) which is unable to figure out the order of arguments. My original idea to solve this (also mentioned by Helmut above) was to fix his initial problem by finally implementing a way to re-use the data structures created by an initial dose3 run by subsequent dose3 runs (given the underlying Packages and Sources files didn't change). Unfortunately I now realize that this idea won't fly either because the mentioned datastructures would also store the build profiles with which source package were initially instructed to be built but Helmut wants to change these in subsequent runs. If nobody has a better idea, maybe this is a wontfix bug? Thanks! cheers, josch
Attachment:
signature.asc
Description: signature