If you're on freshly installed Fedora 23 (x86-64), then
dnf install gtk3-devel.x86_64
gets you everything you need to compile a simple Gtk3 application[1].
However on the same host if you do:
dnf install gtk3-devel.i686
then there's a lot missing before you can compile a 32 bit Gtk3 application[2]. I had to install the following dependencies (found by tedious trial-and-error) before I could compile it:
dnf -y install {pango,pixman,zlib,libpng,expat,mesa-libEGL,libX11,libdrm,libxcb,libXau,libXdamage,libXfixes,libXxf86vm,libXext,mesa-libGL,libXrender,harfbuzz,graphite2,gdk-pixbuf2,atk,cairo-gobject,libXinerama,libXi,libXrandr,libXcursor,libXcomposite,wayland,libwayland-client,libxkbcommon,libwayland-cursor,mesa-libwayland-egl,libepoxy,at-spi2-atk,at-spi2-core,dbus,glib2,glibc}-devel.i686
Is this a bug or is it not expected this would work or I am doing it wrong?
Rich.
[1] For my test I am using the trivial example from here:
https://developer.gnome.org/gtk3/stable/gtk-getting-started.html
[2] To compile the 32 bit application I'm using:
gcc -m32 trivial.c `PKG_CONFIG_LIBDIR=/usr/lib/pkgconfig:/usr/share/pkgconfig pkg-config --cflags --libs gtk+-3.0` -o trivial
On 01/20/2016 04:50 PM, Richard W.M. Jones wrote:
If you're on freshly installed Fedora 23 (x86-64), then
dnf install gtk3-devel.x86_64
gets you everything you need to compile a simple Gtk3 application[1].
However on the same host if you do:
dnf install gtk3-devel.i686
then there's a lot missing before you can compile a 32 bit Gtk3 application[2]. I had to install the following dependencies (found by tedious trial-and-error) before I could compile it:
dnf -y install {pango,pixman,zlib,libpng,expat,mesa-libEGL,libX11,libdrm,libxcb,libXau,libXdamage,libXfixes,libXxf86vm,libXext,mesa-libGL,libXrender,harfbuzz,graphite2,gdk-pixbuf2,atk,cairo-gobject,libXinerama,libXi,libXrandr,libXcursor,libXcomposite,wayland,libwayland-client,libxkbcommon,libwayland-cursor,mesa-libwayland-egl,libepoxy,at-spi2-atk,at-spi2-core,dbus,glib2,glibc}-devel.i686
Is this a bug or is it not expected this would work or I am doing it wrong?
IMO, this is supposed to work => Bug
The big question would be: Where?
Ralf
On Wed, Jan 20, 2016 at 05:59:25PM +0100, Michael Schwendt wrote:
On Wed, 20 Jan 2016 17:32:52 +0100, Ralf Corsepius wrote:
IMO, this is supposed to work => Bug
The big question would be: Where?
It cannot work as long as gtk3-devel relies on pkgconfig(foo) dependencies instead of arch-specific explicit Requires.
Interesting ...
$ rpm -qR gtk2-devel | grep pkgconfig pkgconfig pkgconfig(atk) pkgconfig(cairo) [etc]
$ rpm -q --whatprovides "pkgconfig(atk)" atk-devel-2.18.0-1.fc24.i686 atk-devel-2.18.0-1.fc24.x86_64
Should the pkgconfig() dependencies be modified to contain %_isa or %__isa_bits?
Rich.
On Qua, 2016-01-20 at 17:59 +0100, Michael Schwendt wrote:
On Wed, 20 Jan 2016 17:32:52 +0100, Ralf Corsepius wrote:
IMO, this is supposed to work => Bug
The big question would be: Where?
I bet more in packaging which have some missing %{_isa}
dnf repoquery --requires gtk3-devel.x86_64 > 1
dnf repoquery --requires gtk3-devel.i686 > 2
vi -O 1 2 both requires same pkgconfig(atk) for example,
Somehow dnf repoquery --provides gtk3-devel.x86_64 and dnf repoquery --provides gtk3-devel.i686
should provides different pkgconfig(s) instead the same : pkgconfig(gail-3.0) = 3.18.2
maybe pkgconfig(gail-3.0)(x86-64) and pkgconfig(gail-3.0)(x86-32)
It cannot work as long as gtk3-devel relies on pkgconfig(foo) dependencies instead of arch-specific explicit Requires.
On 01/20/2016 05:59 PM, Michael Schwendt wrote:
On Wed, 20 Jan 2016 17:32:52 +0100, Ralf Corsepius wrote:
IMO, this is supposed to work => Bug
The big question would be: Where?
It cannot work as long as gtk3-devel relies on pkgconfig(foo) dependencies instead of arch-specific explicit Requires.
AFAIU,the problem behind this is, in case of multilibs, there are several providers providing non-arched rpm tags:
Example:
# rpm -q -provides -p libXt-devel-1.1.5-2.fc23.i686.rpm libXt-devel = 1.1.5-2.fc23 libXt-devel(x86-32) = 1.1.5-2.fc23 pkgconfig(xt) = 1.1.5
# rpm -q -provides -p libXt-devel-1.1.5-2.fc23.x86_64.rpm libXt-devel = 1.1.5-2.fc23 libXt-devel(x86-64) = 1.1.5-2.fc23 pkgconfig(xt) = 1.1.5
Apparently, dnf doesn't resolve such deps correctly, but seem to try to resolve such deps either by a "first match" or "primary arch" strategy and doesn't take a depchains an "inherited arch" into account:
# dnf remove libICE-devel libSM-devel libX11-devel libXt-devel
# dnf install libXt-devel.i686 ... Installing: libICE-devel x86_64 1.0.9-3.fc23 fedora 54 k libSM-devel x86_64 1.2.2-3.fc23 fedora 17 k libX11 i686 1.6.3-2.fc23 fedora 616 k libX11-devel x86_64 1.6.3-2.fc23 fedora 984 k libXt i686 1.1.5-2.fc23 fedora 174 k libXt-devel i686 1.1.5-2.fc23 fedora 450 k
[note: libICE-devel.i686, libSM-devel.i686 are missing]
Seems to me as if history is repeating - IIRC, we've had this issue in early stage of yum, as well ;)
Ralf
Michael Schwendt wrote:
On Wed, 20 Jan 2016 17:32:52 +0100, Ralf Corsepius wrote:
IMO, this is supposed to work => Bug
The big question would be: Where?
It cannot work as long as gtk3-devel relies on pkgconfig(foo) dependencies instead of arch-specific explicit Requires.
Sounds like one way forward to fix this is to make pkgconfig dependencies arch'd
-- Rex
Rex Dieter wrote:
Michael Schwendt wrote:
On Wed, 20 Jan 2016 17:32:52 +0100, Ralf Corsepius wrote:
IMO, this is supposed to work => Bug
The big question would be: Where?
It cannot work as long as gtk3-devel relies on pkgconfig(foo) dependencies instead of arch-specific explicit Requires.
Sounds like one way forward to fix this is to make pkgconfig dependencies arch'd
Hrm, thinking on it more, I don't think that can ever work for this purpose. There's no way to know that Requires: foo in a bar.pc pkgconfig file refers to an arch'd foo or not (foo could possibly be noarch).
-- Rex
On Thu, Jan 21, 2016 at 07:41:23AM -0600, Rex Dieter wrote:
Rex Dieter wrote:
Michael Schwendt wrote:
On Wed, 20 Jan 2016 17:32:52 +0100, Ralf Corsepius wrote:
IMO, this is supposed to work => Bug
The big question would be: Where?
It cannot work as long as gtk3-devel relies on pkgconfig(foo) dependencies instead of arch-specific explicit Requires.
Sounds like one way forward to fix this is to make pkgconfig dependencies arch'd
Hrm, thinking on it more, I don't think that can ever work for this purpose. There's no way to know that Requires: foo in a bar.pc pkgconfig file refers to an arch'd foo or not (foo could possibly be noarch).
Right - that is precisely the problem with my current patch:
https://bugzilla.redhat.com/show_bug.cgi?id=1300432#c2
Rich.
On 2016-01-21, Rex Dieter rdieter@math.unl.edu wrote:
Rex Dieter wrote:
Sounds like one way forward to fix this is to make pkgconfig dependencies arch'd
Hrm, thinking on it more, I don't think that can ever work for this purpose. There's no way to know that Requires: foo in a bar.pc pkgconfig file refers to an arch'd foo or not (foo could possibly be noarch).
With rich dependencies we could hack it by depending on pkgconfig(foo) or pkgconfig(foo)%{?_isa}.
-- Petr
I have filed a bug (against gtk3 for now) about this issue:
https://bugzilla.redhat.com/show_bug.cgi?id=1300432
Rich.
On 01/20/2016 08:23 PM, Richard W.M. Jones wrote:
I have filed a bug (against gtk3 for now) about this issue:
I still don't know the cause of this issue, I don't think this is gtk3's fault (alone). It's possible to generate similar breakdowns for many packages (My gut feeling is, this culprit is dnf).
Example: # dnf install usbguard-devel.i686
Ralf
On Thu, Jan 21, 2016 at 04:10:00AM +0100, Ralf Corsepius wrote:
On 01/20/2016 08:23 PM, Richard W.M. Jones wrote:
I have filed a bug (against gtk3 for now) about this issue:
I still don't know the cause of this issue, I don't think this is gtk3's fault (alone). It's possible to generate similar breakdowns for many packages (My gut feeling is, this culprit is dnf).
Example: # dnf install usbguard-devel.i686
I don't know about this package, but for gtk3-devel.i686 I also tried yum-deprecated with the same results.
Rich.
On 01/21/2016 09:27 AM, Richard W.M. Jones wrote:
On Thu, Jan 21, 2016 at 04:10:00AM +0100, Ralf Corsepius wrote:
On 01/20/2016 08:23 PM, Richard W.M. Jones wrote:
I have filed a bug (against gtk3 for now) about this issue:
I still don't know the cause of this issue, I don't think this is gtk3's fault (alone). It's possible to generate similar breakdowns for many packages (My gut feeling is, this culprit is dnf).
Example: # dnf install usbguard-devel.i686
I don't know about this package, but for gtk3-devel.i686
No prob. This was just a random package with fewer deps than gtk3, I picked up for testing.
I also tried yum-deprecated with the same results.
I also tried - same result. I guess, investigating this any further will require pre-dnf Fedora.
Ralf
On Thu, Jan 21, 2016 at 09:39:38AM +0100, Ralf Corsepius wrote:
On 01/21/2016 09:27 AM, Richard W.M. Jones wrote:
I also tried yum-deprecated with the same results.
I also tried - same result. I guess, investigating this any further will require pre-dnf Fedora.
The earliest Fedora I have easy access to in my cloud builder is Fedora 18. That was the version which introduced dnf, but I don't think it was yet the default -- at least 'yum' works in that version and there is no 'yum-deprecated' command.
I tested it now and the same problem exists with yum in Fedora 18.
Fedora 18 was worse actually because there is a file conflict between a file in gtk3-devel.{i686,x86_64}, so you have to uninstall gtk3-devel.x86_64 to do the test.
Rich.
On Wed, 20 Jan 2016 16:50:03 +0100, Richard W.M. Jones wrote:
However on the same host if you do:
dnf install gtk3-devel.i686
then there's a lot missing before you can compile a 32 bit Gtk3 application[2].
There were always missing many %{?_isa} in BuildRequires, I was filing many of them, got some fixed. But now it is even forbidden to use them: https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRequires_and_.25.7B...
IMO it is because it was causing more harm than good due to rpm/yum/dnf never properly supporting those: RFE: 'dnf builddep' should be able to extract the specfile from a .src.rpm and use it for the dependencies https://bugzilla.redhat.com/show_bug.cgi?id=1210276
IIUC Fedora gave up on multi-arch building and you should use mock for that, ISTM multi-arch is now officially supported only for installation.
Jan
On Wed, 20 Jan 2016 21:59:01 +0100, Jan Kratochvil wrote:
On Wed, 20 Jan 2016 16:50:03 +0100, Richard W.M. Jones wrote:
However on the same host if you do:
dnf install gtk3-devel.i686
then there's a lot missing before you can compile a 32 bit Gtk3 application[2].
There were always missing many %{?_isa} in BuildRequires, I was filing many of them, got some fixed. But now it is even forbidden to use them: https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRequires_and_.25.7B...
This is about explicit and automatic Requires, _not_ BuildRequires.
On Wed, Jan 20, 2016 at 5:59 PM, Michael Schwendt mschwendt@gmail.com wrote:
On Wed, 20 Jan 2016 21:59:01 +0100, Jan Kratochvil wrote:
On Wed, 20 Jan 2016 16:50:03 +0100, Richard W.M. Jones wrote:
However on the same host if you do:
dnf install gtk3-devel.i686
then there's a lot missing before you can compile a 32 bit Gtk3 application[2].
There were always missing many %{?_isa} in BuildRequires, I was filing many of them, got some fixed. But now it is even forbidden to use them: https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRequires_and_.25.7B...
This is about explicit and automatic Requires, _not_ BuildRequires.
devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Wouldn't there also be the problem of headers getting clobbered when you do this?
We don't store libraries and headers in such a way that the different arches can coexist without clobbering. That would be possible if we have something like this: /usr/lib/<gcc-platform-id> /usr/include/<gcc-platform-id>
For example, a 32-bit x86 platform would probably use "i686-redhat-linux-gnu", whereas a 64-bit x86 platform would use "x86_64-redhat-linux-gnu".
Without that, it would be tough to guarantee that installing the 32-bit version of a devel package would produce a consistent and sane build compared to an actual 32-bit chroot.
On Wed, 20 Jan 2016 18:45:15 -0500, Neal Gompa wrote:
Wouldn't there also be the problem of headers getting clobbered when you do this?
Not generally. Not all projects generate headers to be arch-specific. At least in the C/C++ world, it is much more common for headers to contain conditionals to handle arch-dependent sections.
Else, yes, it can happen that headers (and sometimes other files such as -config scripts) in multilib -devel packages cause implicit conflicts, which are not acceptable, even if fixing the conflicts has been neglected for a long time.
On 01/21/2016 12:45 AM, Neal Gompa wrote:
We don't store libraries and headers in such a way that the different arches can coexist without clobbering.
Headers being installed to /usr/include must be multilib capable. I.e. they either must be arch-independent or contain sufficient magic (conditionals) to cope with all fedora archs.
That would be possible if we have something like this: /usr/lib/<gcc-platform-id> /usr/include/<gcc-platform-id>
Current practice is /usr/include/ ... for nonarch headers.
/usr/{lib,lib64}/... for arched parts of a package, comprising arched headers.
For example, a 32-bit x86 platform would probably use "i686-redhat-linux-gnu", whereas a 64-bit x86 platform would use "x86_64-redhat-linux-gnu".
Without that, it would be tough to guarantee that installing the 32-bit version of a devel package would produce a consistent and sane build compared to an actual 32-bit chroot.
No, cf. above.
Does anybody still have a non yum-only based x86_64 system? I suspecting and am pretty sure this issue is caused by yet another brokenness in dnf.
Ralf
On Wed, 20 Jan 2016 23:59:01 +0100, Michael Schwendt wrote:
On Wed, 20 Jan 2016 21:59:01 +0100, Jan Kratochvil wrote:
On Wed, 20 Jan 2016 16:50:03 +0100, Richard W.M. Jones wrote:
However on the same host if you do:
dnf install gtk3-devel.i686
then there's a lot missing before you can compile a 32 bit Gtk3 application[2].
There were always missing many %{?_isa} in BuildRequires, I was filing many of them, got some fixed. But now it is even forbidden to use them: https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRequires_and_.25.7B...
This is about explicit and automatic Requires, _not_ BuildRequires.
I was talking from a higher point of view. Yes, the %{?_isa} would be needed in Requires in OP and I was filing such %{?_isa} Bugs for Requires: glibc-devel: Missing %{?_isa} for Requires: libgcc https://bugzilla.redhat.com/show_bug.cgi?id=1289356 [...] Although I was filing even BuildRequires: python: https://bugzilla.redhat.com/show_bug.cgi?id=773708 https://bugzilla.redhat.com/show_bug.cgi?id=773708
This is sure a stupid way as those Bugs could be detected automatically.
The point was that these two issues are very related: %{?_isa} in BuildRequires: commonly not present + now forbidden %{?_isa} in *-devel Requires: commonly not present There is an implication: missing %{?_isa} in *-devel Requires => %{?_isa} in BuildRequires is useless And I claim that in this current state fixing the %{?_isa} in *-devel Requires has only marginal impact. It can only make possible to multi-arch build non-rpm packages (or rpm packages in non-rpm way) - that is you need to specify all the "dnf install FOO-devel.i686" build requirements by hand as the %{?_isa} in BuildRequires must not be present in the *.spec file now.
And I was suggesting it makes more sense to me to give it up and use mock.
Jan
On Wed, 2016-01-20 at 15:50 +0000, Richard W.M. Jones wrote:
If you're on freshly installed Fedora 23 (x86-64), then
dnf install gtk3-devel.x86_64 ......
Is this a bug or is it not expected this would work or I am doing it wrong?
IMO trying to get this (i686 development environment on x86_64 native install) to work reliably and chasing down all the corner cases is futile, leads to confusion instead of improving the developer experience in any significant way compared to using mock and should be declared unsupported.
- Yanko
On Thu, Jan 21, 2016 at 11:10:22AM +0200, Yanko Kaneti wrote:
On Wed, 2016-01-20 at 15:50 +0000, Richard W.M. Jones wrote:
If you're on freshly installed Fedora 23 (x86-64), then
dnf install gtk3-devel.x86_64 ......
Is this a bug or is it not expected this would work or I am doing it wrong?
IMO trying to get this (i686 development environment on x86_64 native install) to work reliably and chasing down all the corner cases is futile, leads to confusion instead of improving the developer experience in any significant way compared to using mock and should be declared unsupported.
The logical consequence of this is we would get rid of multilib entirely.
Rich.
On Thu, 2016-01-21 at 09:38 +0000, Richard W.M. Jones wrote:
On Thu, Jan 21, 2016 at 11:10:22AM +0200, Yanko Kaneti wrote:
On Wed, 2016-01-20 at 15:50 +0000, Richard W.M. Jones wrote:
If you're on freshly installed Fedora 23 (x86-64), then
dnf install gtk3-devel.x86_64 ......
Is this a bug or is it not expected this would work or I am doing it wrong?
IMO trying to get this (i686 development environment on x86_64 native install) to work reliably and chasing down all the corner cases is futile, leads to confusion instead of improving the developer experience in any significant way compared to using mock and should be declared unsupported.
The logical consequence of this is we would get rid of multilib entirely.
Not really. Runtime multilib is quite valuable feature, as any user of closed source blobs (Steam!!) could attest.
- Yanko
Am 21.01.2016 um 14:34 schrieb Yanko Kaneti:
On Thu, 2016-01-21 at 09:38 +0000, Richard W.M. Jones wrote:
On Thu, Jan 21, 2016 at 11:10:22AM +0200, Yanko Kaneti wrote:
On Wed, 2016-01-20 at 15:50 +0000, Richard W.M. Jones wrote:
If you're on freshly installed Fedora 23 (x86-64), then
dnf install gtk3-devel.x86_64 ......
Is this a bug or is it not expected this would work or I am doing it wrong?
IMO trying to get this (i686 development environment on x86_64 native install) to work reliably and chasing down all the corner cases is futile, leads to confusion instead of improving the developer experience in any significant way compared to using mock and should be declared unsupported.
The logical consequence of this is we would get rid of multilib entirely.
Not really. Runtime multilib is quite valuable feature, as any user of closed source blobs (Steam!!) could attest.
the same for wine and windows games
(not that i personally have any i686 package installed)
On Thu, Jan 21, 2016 at 03:34:34PM +0200, Yanko Kaneti wrote:
On Thu, 2016-01-21 at 09:38 +0000, Richard W.M. Jones wrote:
On Thu, Jan 21, 2016 at 11:10:22AM +0200, Yanko Kaneti wrote:
On Wed, 2016-01-20 at 15:50 +0000, Richard W.M. Jones wrote:
If you're on freshly installed Fedora 23 (x86-64), then
dnf install gtk3-devel.x86_64 ......
Is this a bug or is it not expected this would work or I am doing it wrong?
IMO trying to get this (i686 development environment on x86_64 native install) to work reliably and chasing down all the corner cases is futile, leads to confusion instead of improving the developer experience in any significant way compared to using mock and should be declared unsupported.
The logical consequence of this is we would get rid of multilib entirely.
Not really. Runtime multilib is quite valuable feature, as any user of closed source blobs (Steam!!) could attest.
Hmmm. Do we care about closed source blobs?
Actually I really want 'dnf install gtk3-devel.i686' to work, because the alternatives (mock, virtualization) are not very good solutions because they are difficult to automate.
I'm trying to build a 32 bit virt-p2v binary. virt-p2v is free software. Building a 32 bit binary is a useful thing to do since the binary is meant to be copied to ancient (pre-2004) physical hardware in order to virtualize what's running on that hardware.
In the context of Koji or users doing `./configure && make' you can't really fire up a chroot or VM to do part of the build.
Rich.
On 21 January 2016 at 09:10, Yanko Kaneti yaneti@declera.com wrote:
On Wed, 2016-01-20 at 15:50 +0000, Richard W.M. Jones wrote:
If you're on freshly installed Fedora 23 (x86-64), then
dnf install gtk3-devel.x86_64 ......
Is this a bug or is it not expected this would work or I am doing it wrong?
IMO trying to get this (i686 development environment on x86_64 native install) to work reliably and chasing down all the corner cases is futile, leads to confusion instead of improving the developer experience in any significant way compared to using mock and should be declared unsupported.
That would be extremely disappointing.
On Wednesday, January 20, 2016 03:50:03 PM Richard W.M. Jones wrote:
If you're on freshly installed Fedora 23 (x86-64), then
dnf install gtk3-devel.x86_64
gets you everything you need to compile a simple Gtk3 application[1].
However on the same host if you do:
dnf install gtk3-devel.i686
then there's a lot missing before you can compile a 32 bit Gtk3 application[2]. I had to install the following dependencies (found by tedious trial-and-error) before I could compile it:
dnf -y install {pango,pixman,zlib,libpng,expat,mesa-libEGL,libX11,libdrm,libxcb,libXau,lib Xdamage,libXfixes,libXxf86vm,libXext,mesa-libGL,libXrender,harfbuzz,graphite 2,gdk-pixbuf2,atk,cairo-gobject,libXinerama,libXi,libXrandr,libXcursor,libXc omposite,wayland,libwayland-client,libxkbcommon,libwayland-cursor,mesa-libwa yland-egl,libepoxy,at-spi2-atk,at-spi2-core,dbus,glib2,glibc}-devel.i686
Is this a bug or is it not expected this would work or I am doing it wrong?
I am not really sure that people have tested this use case in years. It would be interesting to see if yum-deprecated gave you working results. If so then I would say it is a dnf bug.
However I really think we need to sit down and rethink multilib. I would like to start by changing the multilib method to runtime. So you only get runtime libraries and nothing to build 32 bit apps on 64 bit. For 32 bit building you should just use mock, docker, systemd-nspawn or something else. It would mean we need to make and ship a i386 docker base image if we say use docker.
We have dropped most multilib support already. Today s390x has multilib with s390 and x86_64 multilib with i386.we dropped 32 bit ppc support entirely, we are working to drop s390 which will leave x86_64 standing all alone. Given changes in technologies since x86_64 first became a thing I think we sit back and reevaluate the idea of multilib. Maybe there is better ways to achieve what we want today
Dennis
On 21 January 2016 at 14:25, Dennis Gilmore dennis@ausil.us wrote:
However I really think we need to sit down and rethink multilib. I would like to start by changing the multilib method to runtime. So you only get runtime libraries and nothing to build 32 bit apps on 64 bit. For 32 bit building you should just use mock, docker, systemd-nspawn or something else. It would mean we need to make and ship a i386 docker base image if we say use docker.
We have dropped most multilib support already. Today s390x has multilib with s390 and x86_64 multilib with i386.we dropped 32 bit ppc support entirely, we are working to drop s390 which will leave x86_64 standing all alone. Given changes in technologies since x86_64 first became a thing I think we sit back and reevaluate the idea of multilib. Maybe there is better ways to achieve what we want today
Successfully build and run 20+ year old programs without having to completely rewrite them would be one of the things I want today. In fact it's one of the things I was doing earlier this week.
On Thu, Jan 21, 2016 at 10:10 AM, Ian Malone ibmalone@gmail.com wrote:
On 21 January 2016 at 14:25, Dennis Gilmore dennis@ausil.us wrote:
However I really think we need to sit down and rethink multilib. I would like to start by changing the multilib method to runtime. So you only get runtime libraries and nothing to build 32 bit apps on 64 bit. For 32 bit building you should just use mock, docker, systemd-nspawn or something else. It would mean we need to make and ship a i386 docker base image if we say use docker.
We have dropped most multilib support already. Today s390x has multilib with s390 and x86_64 multilib with i386.we dropped 32 bit ppc support entirely, we are working to drop s390 which will leave x86_64 standing all alone. Given changes in technologies since x86_64 first became a thing I think we sit back and reevaluate the idea of multilib. Maybe there is better ways to achieve what we want today
Successfully build and run 20+ year old programs without having to completely rewrite them would be one of the things I want today. In fact it's one of the things I was doing earlier this week.
Is there a reason that would not work in mock?
josh
On 21/01/16 10:15 -0500, Josh Boyer wrote:
On Thu, Jan 21, 2016 at 10:10 AM, Ian Malone ibmalone@gmail.com wrote:
Successfully build and run 20+ year old programs without having to completely rewrite them would be one of the things I want today. In fact it's one of the things I was doing earlier this week.
Is there a reason that would not work in mock?
A developer who wants to build a 32-bit program on x86_64 might not be in the mock group. Their system administrator might not want to give them access to the mock group, given that it's effectively root, but might be happy to install foobar-devel.i686 for them.
"gcc -m32" is simpler than using a chroot or container.
On Thu, 21 Jan 2016 16:37:01 +0100, Jonathan Wakely wrote:
A developer who wants to build a 32-bit program on x86_64 might not be in the mock group. Their system administrator might not want to
Aren't the multiuser systems a history now with VPSes or even just containers cheaper than a hamburger? Moreover for anyone with any special requirements.
Jan
On 21/01/16 16:49 +0100, Jan Kratochvil wrote:
On Thu, 21 Jan 2016 16:37:01 +0100, Jonathan Wakely wrote:
A developer who wants to build a 32-bit program on x86_64 might not be in the mock group. Their system administrator might not want to
Aren't the multiuser systems a history now with VPSes or even just containers cheaper than a hamburger? Moreover for anyone with any special requirements.
They weren't history two years ago at my last job, but that's two years ago so maybe they are now.
In many large firms in slow-moving industries two years is not very long, but they wouldn't be developing on Fedora anyway.
On Thu, Jan 21, 2016 at 04:49:21PM +0100, Jan Kratochvil wrote:
Aren't the multiuser systems a history now with VPSes or even just containers cheaper than a hamburger? Moreover for anyone with any special requirements.
No. They are incredibly common in schools and in high performance computing.
On Thu, Jan 21, 2016 at 11:37:36AM -0500, Matthew Miller wrote:
Aren't the multiuser systems a history now with VPSes or even just containers cheaper than a hamburger? Moreover for anyone with any special requirements.
No. They are incredibly common in schools and in high performance computing.
And, you might say "But, really, Fedora for that?" -- well, yes. It's reasonably common to provide a Fedora system as a login node because of access to the wider amount of pre-packaged software and newer versions of stuff.
On Thu, Jan 21, 2016 at 10:37 AM, Jonathan Wakely jwakely@fedoraproject.org wrote:
On 21/01/16 10:15 -0500, Josh Boyer wrote:
On Thu, Jan 21, 2016 at 10:10 AM, Ian Malone ibmalone@gmail.com wrote:
Successfully build and run 20+ year old programs without having to completely rewrite them would be one of the things I want today. In fact it's one of the things I was doing earlier this week.
Is there a reason that would not work in mock?
A developer who wants to build a 32-bit program on x86_64 might not be in the mock group. Their system administrator might not want to give them access to the mock group, given that it's effectively root, but might be happy to install foobar-devel.i686 for them.
True, but that is policy beyond the scope of Fedora, not technical reasons for it to not be possible. Also, perhaps such users can use local KVM guests to build on, etc. We cannot account for all such policy decisions various sysadmins make.
"gcc -m32" is simpler than using a chroot or container.
You're arguing convenience. I'm not saying that is wrong, but it is not an answer to the question I asked really.
josh
On 21/01/16 10:52 -0500, Josh Boyer wrote:
On Thu, Jan 21, 2016 at 10:37 AM, Jonathan Wakely jwakely@fedoraproject.org wrote:
On 21/01/16 10:15 -0500, Josh Boyer wrote:
On Thu, Jan 21, 2016 at 10:10 AM, Ian Malone ibmalone@gmail.com wrote:
Successfully build and run 20+ year old programs without having to completely rewrite them would be one of the things I want today. In fact it's one of the things I was doing earlier this week.
Is there a reason that would not work in mock?
A developer who wants to build a 32-bit program on x86_64 might not be in the mock group. Their system administrator might not want to give them access to the mock group, given that it's effectively root, but might be happy to install foobar-devel.i686 for them.
True, but that is policy beyond the scope of Fedora, not technical reasons for it to not be possible. Also, perhaps such users can use local KVM guests to build on, etc. We cannot account for all such policy decisions various sysadmins make.
But if Fedora stops shipping 32-bit -devel packages that doesn't let the admins choose the policy, they *must* tell their users to use mock or containers.
"gcc -m32" is simpler than using a chroot or container.
You're arguing convenience. I'm not saying that is wrong, but it is not an answer to the question I asked really.
True, but it's an answer to "Is there a reason *a developer using Fedora* would *choose to* not work in mock" :-)
Removing multilib -devel packages dictates a particular way of working on developers, which I find a bit surprising.
I hope at least the glibc-devel.i686 package would remain, or I would find it more difficult to use Fedora for my upstream GCC development (which *does* support multilib, and will continue to do so whatever Fedora does).
On 21 January 2016 at 15:15, Josh Boyer jwboyer@fedoraproject.org wrote:
On Thu, Jan 21, 2016 at 10:10 AM, Ian Malone ibmalone@gmail.com wrote:
On 21 January 2016 at 14:25, Dennis Gilmore dennis@ausil.us wrote:
However I really think we need to sit down and rethink multilib. I would like to start by changing the multilib method to runtime. So you only get runtime libraries and nothing to build 32 bit apps on 64 bit. For 32 bit building you should just use mock, docker, systemd-nspawn or something else. It would mean we need to make and ship a i386 docker base image if we say use docker.
We have dropped most multilib support already. Today s390x has multilib with s390 and x86_64 multilib with i386.we dropped 32 bit ppc support entirely, we are working to drop s390 which will leave x86_64 standing all alone. Given changes in technologies since x86_64 first became a thing I think we sit back and reevaluate the idea of multilib. Maybe there is better ways to achieve what we want today
Successfully build and run 20+ year old programs without having to completely rewrite them would be one of the things I want today. In fact it's one of the things I was doing earlier this week.
Is there a reason that would not work in mock?
It would, it would require installing the entire development system in mock though, and shifting data in and out is more awkward than working directly on it. Additionally, notice the:
Given changes in technologies since x86_64 first became a thing I think we sit back and reevaluate the idea of multilib. Maybe there is better ways to achieve what we want today"
Since RHEL/CentOS 7 already does not exist in a native 32bit version I do wonder what would actually be running in a hypothetical mock/container/VM to build and run 32 bit systems down the road if multilib went away.
On 21/01/16 22:24, Ian Malone wrote:
Since RHEL/CentOS 7 already does not exist in a native 32bit version I do wonder what would actually be running in a hypothetical mock/container/VM to build and run 32 bit systems down the road if multilib went away.
CentOS 7 does now have a 32-bit version:
http://seven.centos.org/2015/10/centos-linux-7-32-bit-x86-i386-architecture-...
Paul.
On 22 January 2016 at 09:05, Paul Howarth paul@city-fan.org wrote:
On 21/01/16 22:24, Ian Malone wrote:
Since RHEL/CentOS 7 already does not exist in a native 32bit version I do wonder what would actually be running in a hypothetical mock/container/VM to build and run 32 bit systems down the road if multilib went away.
CentOS 7 does now have a 32-bit version:
http://seven.centos.org/2015/10/centos-linux-7-32-bit-x86-i386-architecture-...
While interesting to know, that is a CentOS SIG effort. If you are using RHEL you presumably aren't supported for it, and I'm giving it as an example of the way things are going. In any case I find this whole 'just build in mock' as a work around for what is basically a packaging problem a rather weak fix. Why is multilib devel install of libraries any more difficult than multilib install of run time libraries? They live in the same place. If the issue is header includes and documentation conflicting, if that's a real problem then shouldn't it be .noarch?
On Fri, Jan 22, 2016 at 6:53 AM, Ian Malone ibmalone@gmail.com wrote:
On 22 January 2016 at 09:05, Paul Howarth paul@city-fan.org wrote:
On 21/01/16 22:24, Ian Malone wrote:
Since RHEL/CentOS 7 already does not exist in a native 32bit version I do wonder what would actually be running in a hypothetical mock/container/VM to build and run 32 bit systems down the road if multilib went away.
CentOS 7 does now have a 32-bit version:
http://seven.centos.org/2015/10/centos-linux-7-32-bit-x86-i386-architecture-...
While interesting to know, that is a CentOS SIG effort. If you are using RHEL you presumably aren't supported for it, and I'm giving it as an example of the way things are going. In any case I find this
If you're using RHEL, then you'd use RHEL to build for RHEL surely. Which means you build on RHEL however it enables you to build 32-bit applications. Sure, you could use Fedora to build for RHEL, but I find that baffling in either the mock or the multilib case. There's just no sanity in expecting something built on Fedora multilib to work on RHEL except in the simplest of cases.
whole 'just build in mock' as a work around for what is basically a packaging problem a rather weak fix. Why is multilib devel install of libraries any more difficult than multilib install of run time libraries? They live in the same place. If the issue is header includes and documentation conflicting, if that's a real problem then shouldn't it be .noarch?
I wasn't suggesting to not fix the packaging bugs. I was going down a thought experiment path with Dennis' suggested dissolution of multilib to see if there were any major consequences. Aside from convenience and historical precedence, I haven't seen much. My apologies if I led you to think I was saying the current issues shouldn't be resolved.
josh
On 22 January 2016 at 13:38, Josh Boyer jwboyer@fedoraproject.org wrote:
On Fri, Jan 22, 2016 at 6:53 AM, Ian Malone ibmalone@gmail.com wrote:
On 22 January 2016 at 09:05, Paul Howarth paul@city-fan.org wrote:
On 21/01/16 22:24, Ian Malone wrote:
Since RHEL/CentOS 7 already does not exist in a native 32bit version I do wonder what would actually be running in a hypothetical mock/container/VM to build and run 32 bit systems down the road if multilib went away.
CentOS 7 does now have a 32-bit version:
http://seven.centos.org/2015/10/centos-linux-7-32-bit-x86-i386-architecture-...
While interesting to know, that is a CentOS SIG effort. If you are using RHEL you presumably aren't supported for it, and I'm giving it as an example of the way things are going. In any case I find this
If you're using RHEL, then you'd use RHEL to build for RHEL surely. Which means you build on RHEL however it enables you to build 32-bit applications. Sure, you could use Fedora to build for RHEL, but I find that baffling in either the mock or the multilib case. There's just no sanity in expecting something built on Fedora multilib to work on RHEL except in the simplest of cases.
Indeed. I don't build for RHEL using Fedora. However it would be unexpected (unprecented?) for Fedora to diverge from RH on handling multilib, and I expect changes here will show up there eventually, hence taking an interest in this issue. Fedora I use at home and don't often have call to build 32bit with (though this would probably be different if I made use of Wine at all).
On Qui, 2016-01-21 at 08:25 -0600, Dennis Gilmore wrote:
I am not really sure that people have tested this use case in years. It would be interesting to see if yum-deprecated gave you working results. If so then I would say it is a dnf bug.
Is not a dnf bug
Somehow dnf repoquery --provides gtk3-devel.x86_64 (or rpm -q --provides gtk3-devel.x86_64 ) and dnf repoquery --provides gtk3-devel.i686
should provides different pkgconfig(s), instead the same, for example: pkgconfig(gail-3.0) = 3.18.2
if gtk3-devel.x86_64 and gtk3-devel.i686 provides the same pkgconfig , is not possible for dnf or yum choose the correct package.
On Thu, Jan 21, 2016 at 04:36:33PM +0000, Sérgio Basto wrote:
On Qui, 2016-01-21 at 08:25 -0600, Dennis Gilmore wrote:
I am not really sure that people have tested this use case in years. It would be interesting to see if yum-deprecated gave you working results. If so then I would say it is a dnf bug.
Is not a dnf bug
Somehow dnf repoquery --provides gtk3-devel.x86_64 (or rpm -q --provides gtk3-devel.x86_64 ) and dnf repoquery --provides gtk3-devel.i686
should provides different pkgconfig(s), instead the same, for example: pkgconfig(gail-3.0) = 3.18.2
if gtk3-devel.x86_64 and gtk3-devel.i686 provides the same pkgconfig , is not possible for dnf or yum choose the correct package.
Correct - I've shown elsewhere in the thread that this bug exists in yum, at least as far back as yum from Fedora 18.
Rich.
On 01/21/2016 10:32 AM, Richard W.M. Jones wrote:
On Thu, Jan 21, 2016 at 04:36:33PM +0000, Sérgio Basto wrote:
On Qui, 2016-01-21 at 08:25 -0600, Dennis Gilmore wrote:
I am not really sure that people have tested this use case in years. It would be interesting to see if yum-deprecated gave you working results. If so then I would say it is a dnf bug.
Is not a dnf bug
Somehow dnf repoquery --provides gtk3-devel.x86_64 (or rpm -q --provides gtk3-devel.x86_64 ) and dnf repoquery --provides gtk3-devel.i686
should provides different pkgconfig(s), instead the same, for example: pkgconfig(gail-3.0) = 3.18.2
if gtk3-devel.x86_64 and gtk3-devel.i686 provides the same pkgconfig , is not possible for dnf or yum choose the correct package.
Correct - I've shown elsewhere in the thread that this bug exists in yum, at least as far back as yum from Fedora 18.
Rich.
It's not a bug. The requires is satisfied.
On Thu, Jan 21, 2016 at 12:53:45PM -0700, Orion Poplawski wrote:
On 01/21/2016 10:32 AM, Richard W.M. Jones wrote:
On Thu, Jan 21, 2016 at 04:36:33PM +0000, Sérgio Basto wrote:
On Qui, 2016-01-21 at 08:25 -0600, Dennis Gilmore wrote:
I am not really sure that people have tested this use case in years. It would be interesting to see if yum-deprecated gave you working results. If so then I would say it is a dnf bug.
Is not a dnf bug
Somehow dnf repoquery --provides gtk3-devel.x86_64 (or rpm -q --provides gtk3-devel.x86_64 ) and dnf repoquery --provides gtk3-devel.i686
should provides different pkgconfig(s), instead the same, for example: pkgconfig(gail-3.0) = 3.18.2
if gtk3-devel.x86_64 and gtk3-devel.i686 provides the same pkgconfig , is not possible for dnf or yum choose the correct package.
Correct - I've shown elsewhere in the thread that this bug exists in yum, at least as far back as yum from Fedora 18.
Rich.
It's not a bug. The requires is satisfied.
Yup, I didn't mean to indicate the bug was in dnf (or yum). They are obviously behaving correctly, and as you say the requires of the packages themselves are wrong.
Rich.
-
Dennis Gilmore -
Ian Malone -
Jan Kratochvil -
Jonathan Wakely -
Josh Boyer -
Matthew Miller -
Michael Schwendt -
Neal Gompa -
Orion Poplawski -
Paul Howarth -
Petr Pisar -
Ralf Corsepius -
Reindl Harald -
Rex Dieter -
Richard W.M. Jones -
Sérgio Basto -
Yanko Kaneti