On 14.03.24 18:52, Christoph Biedl wrote:

Control: tags 1066850 moreinfo

Matthias Klose wrote...

Package: src:python-magic
Version: 2:0.4.27-2
Severity: serious
Tags: sid trixie

the package build-depends on libmagic1, and depends on it. The name was
recently changed to libmagic1t64.

This is not a real problem as libmagic1t64 provides libmagic1, so the dependency can still be resolved.

this is not true on the 32bit time_t64 archs. Debian doesn't build
binary-indep packages on these architectures, but this b-d prevents
doing so (and it does so, because it's impossible to install
python-magic's b-d's on the porter boxes).

Please don't hard-code it, but try to b-d
on libmagic-dev, (...)

About the build dependency src:python-magic -> libmagic1:

So that is ugly, and using libmagic-dev is a simple fix for it. Will do
in the next uplad.

and derive the name of the shared library package from the
libmagic-dev package.

Are you still talking about the build dependency here? Then it's no
issue as the -dev dependency will take care of that.

No, the idea was to b-d on libmagic-dev, and then get the dependency for python3-magic from it.

Question: What is the justifcation for the bug severity? To me, it
is rather "minor".

you can't install the package on the 32bit time_t64 architectures, some
of them still being release architectures. On these archs, libmagic1t64
doesn't provide libmagic1.

Matthias

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

After getting some help in IRC, I guess the problem boils down to:

1. All architectures provide the t64 variant (libmagic1t64).
2. Some architectures no longer provide the old variant (libmagic1), for
example armhf.
3. Therefore, the install dependency of python3-magic must be the t64 variant.

and derive the name of the shared library package from the
libmagic-dev package.

Now replacing one hardcoded binary library dependency with a different
one is not quite the brightest move as this will introduce work should
the libmagic ABI ever change (hasn't happened in 20 years but still).
So it was nicer to do this dynamically during build. That step however
is optional.

Do you have an idea, an existing solution how to do that?

So far I found two ways, and dislike both:

* Derive from apt-cache:

override_dh_gencontrol:
perl -MDebian::Debhelper::Dh_Lib -e \
'addsubstvar ("python3-magic", "misc:Depends", $$ARGV[0])' \
"$$(apt-cache show libmagic-dev | awk '($$1=="Depends:"){print $$2}' | head -n 1)"
dh_gencontrol $@

Querying the apt database from inside a package build feels like a layer violation.

* Abuse dpkg-shlibdeps:

override_dh_gencontrol:
dpkg-shlibdeps -e /usr/bin/file -Tdebian/python3-magic.substvars
dh_gencontrol $@

(Some tweaks to debian/control needed as well.)

This also introduces an install dependency on libc6, and my gut feeling
tells me this was the point to make python3-magic arch:any.

So, is all this worth the efforts? FWIW, I maintain the libmagic
package as well, so being lazy now will just hurt me later.

Christoph

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEWXMI+726A12MfJXdxCxY61kUkv0FAmXzYEkACgkQxCxY61kU kv1eBA/9FrtAS/DcgiqvJ4p49Zk6jLEwluAaEWriKbNoRE19pmZq6ByVUuuGFKOQ 8EjcgtCkVsErggKSYJ6aXFpoJ3VPq+NR+ilp97YMljQVNhYchbU4xX12vcLDyxrw PKzu1k2fqnrwz/1JK/pxwIx1n3Uq1m+Wv/xD6rzG91CCVb7c0lgpetMK/5UIXxNc nCimZjwgsoQDZvQwK0Q69RLLF9+uI+YxAYG05Y299IsV8VvLK9rTGupJ1/L3cBxE IAIaZMLA2W097gPcmIJ94QZXH0xIQydiILyeV1LbcRgI6Dp0hQ+R5o/9ypVan1yH 9CnsIN6k6Vj4iWHSjs5huzFlH4EUk5spqa/ABW/U1mun8o7WBegkQ6cThA1mZQx4 7vYU4gKHpw3c2C3qid0ZOvGfbb4Ivu/RVBn1RHgtMHdRPR19WgW1K+9kxCtju3aI cDKL+JG5mdaUXOjOLdtQIWucEr4SYSrh9lUarCMR0HJym5BboqRT9BosQ4eiRSKA cWjKu18beASFUJBp5sQZ1suWzptDj0lgabXjhHNIa7/ywYNmH0Wbdse9f/n7DK0p yOesHp8xeZOixUH8HFylL9mZTUUIMBmH/00lptCYN5BU/kqSg0wgRFRNHQYcRKji xrhj2cZK05otCW8QWLqWMRXKlCJDWDeWYMYsPUEpWbAXMMwnBig=
=RvtM
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)