Bug#1061344: User input needed: Stop supporting 32 bit architectures with emboss (Was: emboss-lib: identified for time_t transition but no ABI in shlibs)
Hi again, I've filed bug #1062371 RM: emboss [armel armhf i386 hppa m68k powerpc sh4] -- ROM; No support of 32 bit architectures any more Kind regards Andreas. Am Wed, Jan 31, 2024 at 07:53:26AM +0100 schrieb Andreas Tille: > Hi again, > > besides my suggested solution to split up emboss-lib again (and when > doing so make the package emboss-lib a metapackage depending from single > packages to match all its rdepends) I wonder whether we should provide > EMBOSS for 64 bit architectures only. While we probably need to file a > lot of removal requests to 32 bit packages of its rdepends it somehow > fits the reality that these days nobody seriously runs emboss on 32bit > architectures. As explained in the according wiki page[1] other binary > distros are dropping 32-bit at all and Debian rather cares for > automotive, IOT, TVs, routers, plant control, building > monitoring/control, cheap Android phones - nothing that is using EMBOSS. > > I would really like to get some input from *our users* here on the > Debian Med list since I need your response to draw a sensible decision. > > Kind regards > Andreas. > > [1] https://wiki.debian.org/ReleaseGoals/64bit-time > > Am Fri, Jan 26, 2024 at 10:44:09AM +0100 schrieb Andreas Tille: > > Hi Charles, > > > > I wonder how we can properly solve this bug. In the early stage of > > Emboss packaging obviously the packages > > > >libajax6, > >libajax6-dev, > >libnucleus6, > >libnucleus6-dev > > > > existed (thus the remaining Conflicts/Replaces on emboss-lib which can > > probably be removed right now). I wonder whether we should restore those > > single library package per shared library + devel package, merge > > static+shared library in one package or even merge > > > >libacd 6 emboss-lib (>= 6.6.0+dfsg) > >libajax 6 emboss-lib (>= 6.6.0+dfsg) > >libajaxdb 6 emboss-lib (>= 6.6.0+dfsg) > >libajaxg 6 emboss-lib (>= 6.6.0+dfsg) > >libensembl 6 emboss-lib (>= 6.6.0+dfsg) > >libnucleus 6 emboss-lib (>= 6.6.0+dfsg) > > > > in libemboss6 > > > >libepcre 7 emboss-lib (>= 6.6.0+dfsg) > > > > in libemboss-pcre7 (ugly since its a code copy of pcre3 but well, > > that's another battle field) and > > > >libeplplot 3 emboss-lib (>= 6.6.0+dfsg) > > > > in libemboss-plplot3 to express the proper sonames inside the library > > package names. Any more sensible suggestion is pretty welcome. > > > > Kind regards > > Andreas. > > > > -- > > http://fam-tille.de > > -- > http://fam-tille.de > > -- http://fam-tille.de
Bug#1061344: User input needed: Stop supporting 32 bit architectures with emboss (Was: emboss-lib: identified for time_t transition but no ABI in shlibs)
Hi Andreas, I agree that we can remove EMBOSS in all 32-bit platforms. I think that a large fraction of the scientific field has no appetite to do any extra volunteer work to such as accepting our patches to support scientific computations on 32-bit systems in 15 years... Have a nice day, Charles
Bug#1061344: User input needed: Stop supporting 32 bit architectures with emboss (Was: emboss-lib: identified for time_t transition but no ABI in shlibs)
Hi again, besides my suggested solution to split up emboss-lib again (and when doing so make the package emboss-lib a metapackage depending from single packages to match all its rdepends) I wonder whether we should provide EMBOSS for 64 bit architectures only. While we probably need to file a lot of removal requests to 32 bit packages of its rdepends it somehow fits the reality that these days nobody seriously runs emboss on 32bit architectures. As explained in the according wiki page[1] other binary distros are dropping 32-bit at all and Debian rather cares for automotive, IOT, TVs, routers, plant control, building monitoring/control, cheap Android phones - nothing that is using EMBOSS. I would really like to get some input from *our users* here on the Debian Med list since I need your response to draw a sensible decision. Kind regards Andreas. [1] https://wiki.debian.org/ReleaseGoals/64bit-time Am Fri, Jan 26, 2024 at 10:44:09AM +0100 schrieb Andreas Tille: > Hi Charles, > > I wonder how we can properly solve this bug. In the early stage of > Emboss packaging obviously the packages > >libajax6, >libajax6-dev, >libnucleus6, >libnucleus6-dev > > existed (thus the remaining Conflicts/Replaces on emboss-lib which can > probably be removed right now). I wonder whether we should restore those > single library package per shared library + devel package, merge > static+shared library in one package or even merge > >libacd 6 emboss-lib (>= 6.6.0+dfsg) >libajax 6 emboss-lib (>= 6.6.0+dfsg) >libajaxdb 6 emboss-lib (>= 6.6.0+dfsg) >libajaxg 6 emboss-lib (>= 6.6.0+dfsg) >libensembl 6 emboss-lib (>= 6.6.0+dfsg) >libnucleus 6 emboss-lib (>= 6.6.0+dfsg) > > in libemboss6 > >libepcre 7 emboss-lib (>= 6.6.0+dfsg) > > in libemboss-pcre7 (ugly since its a code copy of pcre3 but well, > that's another battle field) and > >libeplplot 3 emboss-lib (>= 6.6.0+dfsg) > > in libemboss-plplot3 to express the proper sonames inside the library > package names. Any more sensible suggestion is pretty welcome. > > Kind regards > Andreas. > > -- > http://fam-tille.de -- http://fam-tille.de