On 05. 08. 19 15:36, Kaleb Keithley wrote:
> There is a proposal[1] in upstream GlusterFS to drop 32-bit arches.
>
> The original proposal was to drop 32-bit with GlusterFS-7. GlusterFS-7 will land
> in Fedora 31/rawhide soon. More than likely though it will not be official until
> GlusterFS-8, which will probably land, accordingly, after Fedora 31 GA in Fedora
> 32/rawhide.
>
>
>
> [1] https://github.com/gluster/glusterfs/issues/702
What about the dependent packages?
$ repoquery --repo=rawhide{,-source} --whatrequires glusterfs-devel
glusterfs-api-devel-0:6.4-3.fc31.i686
glusterfs-api-devel-0:6.4-3.fc31.x86_64
libvirt-0:5.5.0-2.fc31.src
qemu-2:4.1.0-0.1.rc2.fc31.src
samba-2:4.10.6-0.fc31.2.src
uwsgi-0:2.0.18-2.fc31.src
Er, what about them? AIUI, there isn't going to be a i686 Fedora in F31 and beyond. That just leaves armv7hl. Is anyone really running libvirt, qemu, or storage on such platforms? If they are, the number must be vanishingly small. (My own experience with virt on ARM makes me believe that the that the number must be truly microscopic.) Of those that are, is there a reason they can't keep running glusterfs-7 on F30 or F31 indefinitely if they really need 32-bit gluster?
$ repoquery --repo=rawhide{,-source} --whatrequires glusterfs-api-devel
gluster-block-0:0.4-4.fc31.src
glusterfs-coreutils-0:0.3.1-2.fc31.src
libvirt-0:5.5.0-2.fc31.src
nfs-ganesha-0:2.8.2-3.fc31.src
qemu-2:4.1.0-0.1.rc2.fc31.src
samba-2:4.10.6-0.fc31.2.src
scsi-target-utils-0:1.0.70-9.fc31.src
tcmu-runner-0:1.1.3-2.fc26.src
uwsgi-0:2.0.18-2.fc31.src
tcmu-runner and scsi-target-utils is only for gluster-block, which, by extension should also drop 32-bit at the same time. Likewise, glusterfs-coreutils should also drop 32-bit support.
That only leaves ganesha and samba, which can drop their FSAL_GLUSTER and VFS_GLUSTER plug-ins on 32-bit. Something they have already had to do for Ceph-14 in Fedora 30.
--
Kaleb