[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Handling Multi-Arch packages that must be installed for every enabled architecture?

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

Reply to: