What's the problem of using a virtual package?

What's the problem of using a virtual package?

https://packages.ubuntu.com/search?keywords=libz-dev&searchon=names

https://packages.ubuntu.com/bionic/libz-dev

@promag

What's the problem of using a virtual package?

Thanks! Updated.

@hebasto I've just asked what is the problem of virtual packages 😅 maybe we shouldn't use them? I don't have a strong opinion..

@hebasto I've just asked what is the problem of virtual packages sweat_smile maybe we shouldn't use them? I don't have a strong opinion..

https://www.debian.org/doc/debian-policy/ch-binary.html#virtual-packages:

All packages should use virtual package names where appropriate, and arrange to create new ones if necessary. They should not use virtual package names (except privately, amongst a cooperating group of packages) unless they have been agreed upon and appear in the list of virtual package names.

Concept NACK - unless I'm misunderstanding something.

Can you post some build logs or output? What's the actual error this is fixing? From #18536:

Also the build system didn't find zconf.h header in the depends/armv7l-unknown-linux-gnueabihf/include directory.

Which build system? If it's a Qt precondition that's failing, that sounds like something that needs to be fixed in Qt. Do you still see the same issue if you test with a newer version? i.e #19716.

-system-zlib is the one we build in depends, and it should be being used for the Qt build (if it's not it should be removed, as there'd be point in building it). I don't think the solution to your issue is to bypass that zlib an install other headers.

I'd like us to revisit all of our Qt hacks as part of #19716, as it's quite possible that a bunch of them are no-longer required, maybe we no-longer need a split out zlib (In any case, Qt also seems to be migrating away from zlib to zstd), and don't want to sink a bunch of time trying to solve issues now that may just disappear very soon.

Do you still see the same issue if you test with a newer version? i.e #19716.

Build #19716 (3f4fe21) on Linux x86_64:

$ dpkg-query --show zlib1g-dev libz-dev
dpkg-query: no packages found matching zlib1g-dev
dpkg-query: no packages found matching libz-dev
$ make -C depends qt
# no errors

Not tested on ARM though.

Do you still see the same issue if you test with a newer version? i.e #19716.

Build #19716 (3f4fe21) on ARM 32-bit:

$ uname -srm
Linux 4.14.191-odroidxu4 armv7l
$ dpkg-query --show zlib1g-dev libz-dev
dpkg-query: no packages found matching zlib1g-dev
dpkg-query: no packages found matching libz-dev
$ make -C depends qt
...
compiling ../../corelib/io/qipaddress.cpp
compiling ../../corelib/io/qfiledevice.cpp
compiling ../../corelib/io/qresource.cpp
../../corelib/io/qresource.cpp:64:12: fatal error: zconf.h: No such file or directory
   64 | #  include <zconf.h>
      |            ^~~~~~~~~
compilation terminated.
make[2]: *** [Makefile:4219: .obj/qresource.o] Error 1
make[2]: Leaving directory '/home/hebasto/bitcoin/depends/work/build/armv7l-unknown-linux-gnueabihf/qt/5.15.0-39f03cb2eac/qtbase/src/tools/bootstrap'
make[1]: *** [Makefile:65: sub-bootstrap] Error 2
make[1]: Leaving directory '/home/hebasto/bitcoin/depends/work/build/armv7l-unknown-linux-gnueabihf/qt/5.15.0-39f03cb2eac/qtbase/src'
make: *** [funcs.mk:262: /home/hebasto/bitcoin/depends/work/build/armv7l-unknown-linux-gnueabihf/qt/5.15.0-39f03cb2eac/qtbase/.stamp_built] Error 2
make: Leaving directory '/home/hebasto/bitcoin/depends'

@hebasto how do you want to progress here? As mentioned, we aren't going to merge these changes as-is. If you'd like to continue investigating/look at a different approach, could you turn this into a draft?