Re: 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
Re: User input needed: Stop supporting 32 bit architectures with emboss (Was: emboss-lib: identified for time_t transition but no ABI in shlibs)
On 31/01/2024 10:08, Andreas Tille wrote: [...] running 32bit systems? Can you forward this question to them? Or more generally: Wouldn't it make sense if people doing Debian based bioinformatics would subscribe this list and speak here? Hi, Andreas. Yes, you're right, and I've forwarded your email... Thanks, Tony. -- Minke Informatics Limited, Registered in Scotland - Company No. SC419028 Registered Office: 3 Donview, Bridge of Alford, AB33 8QJ, Scotland (UK) tel. +44(0)19755 63548http://minke-informatics.co.uk mob. +44(0)7985 078324mailto:tony.tra...@minke-informatics.co.uk
Re: User input needed: Stop supporting 32 bit architectures with emboss (Was: emboss-lib: identified for time_t transition but no ABI in shlibs)
Hi Tony, Am Wed, Jan 31, 2024 at 09:57:32AM + schrieb Tony Travis: > The only people I know still using 32-bit software are doing BLAST etc on > older Raspberry Pi's. However, AFAIK, the default Raspberry Pi OS (based on > Debian Bullseye) is 32-bit even though the newer Raspberry Pi have 64-bit > processors. Personally, I don't think it's worth the effort to support > 32-bit software these days. I don't use EMBOSS any longer. Thanks a lot to your insight. Do you have any contact to those people running 32bit systems? Can you forward this question to them? Or more generally: Wouldn't it make sense if people doing Debian based bioinformatics would subscribe this list and speak here? Kind regards Andreas. -- http://fam-tille.de
Re: User input needed: Stop supporting 32 bit architectures with emboss (Was: emboss-lib: identified for time_t transition but no ABI in shlibs)
On 31/01/2024 06:53, Andreas Tille wrote: 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. Hi, Andreas. The only people I know still using 32-bit software are doing BLAST etc on older Raspberry Pi's. However, AFAIK, the default Raspberry Pi OS (based on Debian Bullseye) is 32-bit even though the newer Raspberry Pi have 64-bit processors. Personally, I don't think it's worth the effort to support 32-bit software these days. I don't use EMBOSS any longer. Bye, Tony. -- Minke Informatics Limited, Registered in Scotland - Company No. SC419028 Registered Office: 3 Donview, Bridge of Alford, AB33 8QJ, Scotland (UK) tel. +44(0)19755 63548http://minke-informatics.co.uk mob. +44(0)7985 078324mailto:tony.tra...@minke-informatics.co.uk
Re: 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
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
