[Pkg-utopia-maintainers] Bug#1042981: Multiarch pitfall: polkitd fails to start if not installed in native architecture

[Michael Biebl]

On Wed, 9 Aug 2023 04:05:43 +0200 Bertram Felgenhauer <int-e at gmx.de> wrote:
> Luca Boccassi wrote:
> [...]
> > I don't think this is something we should facilitate by default or
> > spend any energy on.
> >
> > You can correct me if I'm wrong, but I don't see any good reason why
> > anybody would need to run a polkitd:i386 on an otherwise amd64 system.
> > It's not what happens by default if you have i386 enabled and you type
> > 'apt install polkitd' or so.
> 
> I agree that there isn't a good reason, and I'm not sure how I ended
> up in that situation in the first place (the log files don't go back
> far enough). One thing I do know is that polkitd:i386 was marked as
> automatically installed, so I almost certainly did not make that
> decision deliberately.
> 
> My speculation is that this happened while satisfying dependencies for
> a third party i386 application. That meant installing required 32 bit
> libraries, and one of them must have come with a polkitd dependency,
> and the i386 version was selected because I was installing an i386
> package.
> 
> Anyway, I reported this because I assumed that pinning packages to the
> native architecture was easy, so it would be justified even for this
> (hopefully!) rare scenario... apparently that's not the case.
> 

As mentioned, unfortunately there is no way to express this dependency 
in a strait forward way.

I've contemplated dropping the Multi-Arch: foreign notation in systemd 
and maybe also for policykit-1.

Is there a valid use case where we need/want a foreign systemd/policykit-1?



Michael


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-utopia-maintainers/attachments/20240312/31223a70/attachment.sig>