On Sat, Jun 25, 2016 at 12:04:58PM -0700, Josh Triplett wrote: > > See https://wiki.debian.org/HelmutGrohne/MultiarchSpecChanges (and > > links) for more examples, potential solutions and problems/shortcomings > > from each of them. > > The "Install-Same-As" header on that page looks ideal for this case. The devil is in the details, e.g.: "It is only considered installed if it is installed for all architectures that the listed package is installed for" which translates roughly to "implement it in ALL tools, wait for these tools to be released as Debian stable, use it in stable+1" as "considered installed" is a dpkg thing. It also forbids the use of "magic" as hat doesn't play nice with hard rules about package installation states. > Do you know if anyone has looked into what it would take to implement > Install-Same-As in apt? I haven't and so I somehow doubt anyone else has, but who knows… The problem with a possible implementation is that it is in effect a "conditional auto-install enhances" and conditions are hard to implement. Theoretically it is possible to implement that type of conditions with a bunch of virtual packages as a workaround, but in practice apts dependency resolver will not like it, for roughly the same reasons it isn't as good as aptitude in solving sudoku puzzles (not that aptitude will invite you with open arms either, it will just not slam the door in your face). So, an implementation effecting all libapt users instantly via a workaround I would consider highly unlikely. If we talk implementing conditions for real, we are in the flying pigs for human transport department. That would leave us with adding it as "magic" somewhere between apt(-get) and libapt which depending on where it is placed exactly will effect more or less other libapt users which is very rougly proportional to the complexity of implementing the magic in that place. And in all the other places elsewhere to catch the rest of the fish. Disclaimer: This is just an educated guess. I could be entirely wrong. It would be more predictable if more than a few rough ideas existed. Cornercases like upgrading existing systems, opt-in/out configuration and syntax, if multiple packages are mentioned – assuming that is legal – is it an OR or an AND and if the later, does OR exist as | then?, is it a versioned relation, keeping API and/or ABI, what if v2 of a package adds/modifies/removes the field, interaction with autoremove……… Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature