[Aptitude-devel] Bug#836567: Bug#836567: aptitude: [PATCH] aborts on encountering new DepCompareOp flags

[David Kalnischkies]

On Sat, Sep 17, 2016 at 10:32:53PM -0400, Aaron M. Ucko wrote:
> > On a first glance, using the module operator rather than bitwise
> > operations looks a bit odd.
> 
> It's unconventional, but should optimize to bitwise masking in practice
> because the modulus is a constant power of two.  Using an explicit mask
> would be cleaner, but AFAICT apt's headers don't predefine one.

From the apt side I can confirm that I 'recently' added new flags
(specifically in 8c7af4d4 on Thu Jul 16 11:15:25 2015).

The flags are more for internal record keeping rather than needing to be
checked explicitly, but the context ("subsumes") scares me a bit:

MultiArchImplicit can be subsumed although it is unlikely that it ever
will. Those dependencies are needed to translate MultiArch to
SingleArch, which means e.g. Breaks&Replaces != this_version for
M-A:same packages on all other architecture siblings.

ArchSpecific is similar. It sounds like it would be important to check,
but the dependencies are formed in a way that this works without
a resolver 'thinking' about (– for your and my [mostly my really] safety
I will spare you the details on how that is done).


So, why the flags at all? MultiArch worked without them just fine, the
problem they solve is if you for some reason need to know which
dependency was explicitly written in the Packages stanza (and how) vs.
a dependency libapt invented, which is nontrivial to figure out if you
just get handed a dependency and are supposed to tell if its invented or
not, but apt e.g. needs that for its external solver/planner support or
'apt depends foo'.


I /guess/ you will be fine by ignoring these flags in the usecases of
the subsumes method, but that might not be the case for future flags
(who knows what I will do next… *evil laughter*) and if that would be my
method I would opt for not subsuming if the flags do not match
(excluding or – although, not sure if that is really true in all cases,
but that works for a while now, so I will accept that as given without
thinking about it). In practice these dependencies will not be subsumed
in most (= I would say all, but if you are an 'evil' maintainer you can
do it. Practical use is subzero through) cases even if you would allow
it anyhow.

Hope that adding some context helps here.


Best regards

David Kalnischkies
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/aptitude-devel/attachments/20160918/5f685786/attachment.sig>