Hello thread. Stefano Zacchiroli wrote: > [ Explicit Cc to the people which expressed interest in this topic. > R-T/M-F-T set to deity@l.d.o as the most appropriate forum where to > discuss this. Let me know if I should keep the CC. ] Thanks. Yes, I'm subscribed to deity- :) > - Error reporting: currently there is no description about how the > solver reports error to the package manager (e.g. unsolvable > dependencies). It's rather easy to do, but requires consideration of > the possible cause of errors and how the package manager wants to > explain them to the user. Some error stanzas were proposed in the thread, look fine for me. > - Interactive solving: above I've implicitly assumed that solving is > always batch, which is not the case. I've a basic interaction protocol > that addresses this, but I would first like to agree on the batch case > as most of the above will be reused in the interactive case. Skipping that before other things got agreed on... > - Performances: I've the feeling that a big pipe of plain text can be a > bottleneck; we can image a binary equivalent, but first it'd be better > to have numbers about the actual impact of the pipe. For this my position just as before: not a problem :) > - Implementations status: > * Eugene used to have a preliminary implementation of this in CUPT, > then due to my delay it has not been maintained. Eugene: do you > think it would be easy to port the implementation to the above > format? I maintained that external resolver wrapper in Cupt so it should work for the that copy of CUDF protocol you had when I wrote my last mail in those our thread some months ago. Can you provide a formal or informal list of changes in CUDF so I don't need to read all two documents fully to find the protocol changes since that time? > * Julian was waiting for me on a format proposal: here we go! :-) > > - Solution description: the above returns solution in "here is the > new package status" style. Julian was instead proposing something like > "here is a diff from the previous package status". Mine looks cleaner > to me, but obviously more bloated. I disagree. In case we upgrade something like 2/3 of the system and more, the diff approach is even bigger, even without a fact it's more complicated without any practical gain IMO. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Developer
Attachment:
signature.asc
Description: OpenPGP digital signature