On Sun, May 04, 2014 at 09:50:01PM +0200, Stefano Zacchiroli wrote:
> 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 :-))
We really should not hurry to action here ;) , but after telling myself
that I would merge & fixup for a few weeks now (before your last mail),
I just did it today and should therefore also find its way into apt
proper in a few months… or maybe a bit quicker…
> http://git.upsilon.cc/?p=apt.git;a=shortlog;h=refs/heads/zack/edsp-0.5-no-cmdline
So, for the record: This one I have merged with and did assorted fixes
for EDSP on top of that. Didn't had the time to work on implementing
pinning support for the external resolver 'apt' now through (– I have
some hopes that the new APT-Release field could help a bit with it).
[Not that anyone would really care about this toy anyway]
> > > > 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?
Not really. APT terminology is a bit different for historical reasons
compared to what "normal" people would expect. For us, a package has a
name and an architecture ('PkgIterator'), if we refer to all packages
with the same name we use 'GrpIterator' (I should have used something
else, as Group really doesn't fit that well. In comments I tend to use
sibling, although mostly referring to M-A:same packages then…).
> - 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 presume you mean Install/Remove field in Request stanza
(Upgrade is a yes/no field). If so, yes: FullName() is used in
EDSP::WriteRequest(…) which always does "pkg:arch".
Best regards
David Kalnischkies
Attachment:
signature.asc
Description: Digital signature