On Wed, Jan 15, 2014 at 02:57:01PM +0100, David Kalnischkies wrote: > (picking up were I left nearly a month ago… sorry again) Tell me about it... My apologies for the delay as well. Let's just hope we can make the next freeze with these changes :-)) I drop the debate about cmdline for this email; I've some follow-up comments on it, but it is probably more useful to first spend our time on the changes that seem consensual: AFAICT they amount to all patches I've submitted *except* the cmdline one. Please correct me if I'm wrong. I've therefore rebased my changes against current APT (debian/sid, as that seems to be the most current branch), moved the cmdline patch to be the last one, and pushed them here: http://git.upsilon.cc/?p=apt.git;a=shortlog;h=refs/heads/zack/edsp-0.5 http://git.upsilon.cc/?p=apt.git;a=shortlog;h=refs/heads/zack/edsp-0.5-no-cmdline The second branch does not contain the cmdline patch at all. Are you OK with it? If so, can you please merge it? (See below for the pending documentation update, which I think can be decoupled and submitted separately.) > > > and the documentation should be check for sentences suggesting that > > > the package name alone is an identifier. The doc for APT-Candidate > > > e.g. sounds a bit like it. > > > Maybe you can show me how would you change the documentation for > > APT-Candidate? Once I get what you mean here, I'll be happy to reread > > the protocol documentation and propagate the change wherever is needed. > > Sure. APT-Candidate doc says "When set to `yes`, the corresponding > package is the APT candidate for installation among all available > packages with the same name." which isn't true in Multi-Arch world as > libfoo:i386 and libfoo:amd64 can have different candidates (usually > with undesired consequences), but have the same name. I've looked into this and I can easily fix that specific occurrence by just referring to "name:architecture" identifiers, but I think it'd be best to generalize that notion as "EDSP package identifier", or something, and adapt the rest of the EDSP documentation to match. To do so I could use some help though: - is there a proper term for "architecture qualified" packages in APT, which I could use to talk about "package:arch" strings without introducing new terminology? - can I assume that all package "names" that APT passes to EDSP are actually arch-qualified? In particular, can I assume that "Install:" fields will always come with arch attached? How about "Upgrade:" and "Remove:"? They do in my tests, but they have been by no means exhaustive. I'll be happy to submit this as a separate commit/patch once I'm sure about what I should write :-) Thanks for bearing with me, Cheers. -- Stefano Zacchiroli . . . . . . . zack@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
Attachment:
signature.asc
Description: Digital signature