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
Description: PGP signature
_______________________________________________ Aptitude-devel mailing list Aptitudefirstname.lastname@example.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel