Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages
On Saturday, April 6, 2024 7:39:10 A.M. CDT Michael R. Crusoe wrote: > On 29/03/2024 19.44, Steven Robbins wrote: > > I am left with a question whether [reactively dropping troublesome > > architectures] is what you are proposing, or > > whether you mean to preemptively restrict the architectures even when > > they are not troublesome? I would support the former but the latter > > position seems unwarranted to me. > > At least the first, but preferably also the second. Why waste the computing > resources / climate damage / maintainer time when that does not benefit our > users? I guess I would say that, to me, the contention that there is a waste of resources like maintainer time is unproven. I have read all the replies but saw nothing that convinces me of that. What is your estimate of fraction of troublesome packages? > Yes, it is true that compiling for 32-bit and/or big-endian architectures > occasionally highlights coding errors that were otherwise hidden and could > cause problems later. But I'm proposing that it isn't worth it, and that if > a member of the team wishes to restrict the architectures built, they > should do so. To be very precise: I absolutely agree with the position that one doesn't need to adopt heroic efforts to deal with issues on minority architectures - which, in my mind, includes all non-release architectures. As I say, I adhere to this myself and years ago restricted ITK for this reason. Under current policy. In my case, ITK was far and away an outlier. Is your experience different? If we were to adopt policy language that makes it easier to "opt out" of universal architecture coverage - but not change the default - what fraction of packages do you expect you'd choose to opt out on? At this point, I don't see a need to change the default to "64 bits only" for everything in the debian-med umbrella. That seems counter to the Debian spirit. -Steve signature.asc Description: This is a digitally signed message part.
Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages
On 02/04/2024 07.54, Andreas Tille wrote: Hi, Am Mon, Apr 01, 2024 at 09:12:49PM +0200 schrieb Sascha Steinbiss: New packages that aren't "Architecture: all": 1. Add "architecture-is-64-bit" and "architecture-is-little-endian" to the "Build-Depends" list in "debian/control". Nice, didn't know about these virtual packages before. Makes sense for new packages -- would this result in an equivalent effect as restricting the "Architecture" list in all binary packages? If we agree about the policy to restrict new packages to the said architectures I'd recommend adding this to our package template[1]. Draft MR is at https://salsa.debian.org/med-team/community/package_template/-/merge_requests/2 ; to be merged after the policy is accepted ; comments appreciated there OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages
On 30/03/2024 01.00, Diane Trout wrote: On Thu, 2024-03-28 at 14:51 +0100, Michael R. Crusoe wrote: Like all policy proposals, this is not meant to be a hard rule for all time. We can and should revisit the issue later! What do you think of the policy being instead of "-med team packages MUST support all current Debian architectures", "-med team packages (CAN or SHOULD) try to support all current Debian architectures." Thank you for introducing this phrasing. I don't think there is a current Debian-Med team policy on architecture support. And from what I can see, there is nothing in the policy of Debian itself that packages SHOULD or MUST support all official Debian architectures. I would suggest "-med team packages SHOULD try to support all 64-bit little-endian architectures. Team packages are allowed to exclude 32-bit and/or big-endian architectures without justification." More details in the MR that I am preparing. Many packages do work fine, but some make no sense without being able to access much more than 4G of memory or have picky CPU architecture dependencies. I don't think the team should automatically turn off all more obscure architectures, but it seems very reasonable to be quite willing disable builds for things that cause problems outside of x86_64/arm64. And riscv64, which I predict will be the next big architecture for scientific computing in a few years. Which is why I'm proposing that we cast a wider net using "64-bit and little-endian". OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages
On 29/03/2024 19.44, Steven Robbins wrote: On Thursday, March 28, 2024 8:51:01 A.M. CDT Michael R. Crusoe wrote: Therefore I personally conclude that: Support Debian-Med packages for 32-bit and/or big-endian architectures is not a good use of our limited resources. I am left with a question whether that is what you are proposing, or whether you mean to preemptively restrict the architectures even when they are not troublesome? I would support the former but the latter position seems unwarranted to me. At least the first, but preferably also the second. Why waste the computing resources / climate damage / maintainer time when that does not benefit our users? Yes, it is true that compiling for 32-bit and/or big-endian architectures occasionally highlights coding errors that were otherwise hidden and could cause problems later. But I'm proposing that it isn't worth it, and that if a member of the team wishes to restrict the architectures built, they should do so. Like all policy proposals, this is not meant to be a hard rule for all time. We can and should revisit the issue later! Absolutely. The working set of machines does change over time as you mention yourself. I remember doing neuroinformatics research coding on SGI IRIX machines -- which will surely date me. :-) :-D OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages
On 29/03/2024 07.21, Andreas Tille wrote: Hi, I'm personally fine with Michaels suggestion in general. :+1: Am Fri, Mar 29, 2024 at 10:13:40AM +0530 schrieb Nilesh Patra: On 28 March 2024 7:21:01 pm IST, "Michael R. Crusoe" wrote: There are also packages inside debian med umbrella which are not necessarily related to medicine or bioinformatics. These include some general purpose python packages, some C/C++ libraries et. al. There are packages that reverse-depend on the same. I don't think it's a good idea to remove 32 bit support in *all* the packages that are under our umbrella, but probably only the ones that are end-user applications. When reading Michaels proposal I also was thinking about generic libraries we are packaging as pre-dependencies for our end-user applications. I'd be fine with mentioning those as exceptions from what I consider perfectly sensible for the packages that are really targeting at our user base. Ack. It may be good to move packages not related to medicine to different teams over time but some of them actually don't fit into any availability team as per my understanding and may have to be moved to debian/ namespace. What do you think? I'm not convinced that moving package out of our focus is a good idea. When we did so in the past these packages somehow went out of our focus and we hear back from them only by testing removal warnings. I have no problem with moving packages if there is some request from somewhere else and thus there is some convincing interest that the package is maintained properly. But I would not browse the packages maintained by our team, check which might be of general interest, seek in what other team it might be appropriate, become a member of that team and maybe learn that this team has quite a different policy than we have (as I learned in DPT recently). In short: Keep on maintaining what we have and apply common sense where to restrict the architectures sensibly. BTW. actively restricting the architectures for existing packages just creates work for no use. I think we should simply focus on new packages and those that create some troublesome bug reports that we can deal with by removing unused architectures. Sure, I'll adjust the proposal based upon this feedback and similar comments from others. One other hint: I consider it a good idea to forward our proposed change of policy to debian-devel@l.d.o (once we agreed upon the change - maybe in some MR) for two reasons: 1. There might be a chance we have overlooked something. 2. There might be other teams that are interested in a similar change of policy. This is reasonable, sure. OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages
On 29/03/2024 05.43, Nilesh Patra wrote: On 28 March 2024 7:21:01 pm IST, "Michael R. Crusoe" wrote: Alas this is an involved process. If we have to do it a lot, it would be nice if someone writes a tool to automate any aspect of the above! --- Fweh, that's a long email. Please do share your feedback here There are also packages inside debian med umbrella which are not necessarily related to medicine or bioinformatics. These include some general purpose python packages, some C/C++ libraries et. al. There are packages that reverse-depend on the same. I don't think it's a good idea to remove 32 bit support in *all* the packages that are under our umbrella, but probably only the ones that are end-user applications. I hear you, thanks. It may be good to move packages not related to medicine to different teams over time but some of them actually don't fit into any availability team as per my understanding and may have to be moved to debian/ namespace. Sure, no reason to abandon a package we care about if there isn't a welcoming team to receive it. What do you think? and on the Debian-Med Matrix channel for instant discussions: https://app.element.io/#/room/#debian-med:matrix.org I'll be happy to open another thread about it, but while we are at it, do you think it makes sense to make this as our official communication media? Most of us don't hang out on #debian-med IRC and it would be a little misleading for someone wanting to contact us. Should we just close the IRC channel and endorse the matrix channel as the official one? The current Debian-Med policy doesn't even mention the IRC channel. I agree, lets make the matrix room official! → https://salsa.debian.org/med-team/policy/-/merge_requests/2 Thanks, Nilesh OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages
On 01/04/2024 21.12, Sascha Steinbiss wrote: Hi all, first of all thanks Michael for this idea and also for the elaborate proposal email that outlines the intended way to go quite well. Thanks! [...] Support Debian-Med packages for 32-bit and/or big-endian architectures is not a good use of our limited resources. Agreed. If there is agreement with this, then I would like an amend the Debain-Med team policy to make it clear that we, as a community of package maintainers and users, are okay with removing support for 32-bit and/or big-endian systems without discussion. I'd probably not go as far as to eagerly _remove_ all support for 32-bit as in RM'ing existing packages that still build and work fine. I'd rather like to see such a policy change to illustrate a common position that we'd rather disable an architecture and RM its binaries rather than fix a non-trivial issue on that platform, which might block a testing transition or cause some other roadblocks for the archs we actually care about. I know that many others in Debian care about their specific niche architecture and would be offended at some random maintainer just dismissing their subjectively reasonable request to fix things. Making it known beforehand where Debian Med puts its focus would help in making such situations feel less personal. How to make implement this policy with the tools available to us in 2024. New packages that aren't "Architecture: all": 1. Add "architecture-is-64-bit" and "architecture-is-little-endian" to the "Build-Depends" list in "debian/control". Nice, didn't know about these virtual packages before. Makes sense for new packages -- would this result in an equivalent effect as restricting the "Architecture" list in all binary packages? Yes, but with the benefit that we don't have to add in new 64-bit/little-endian archs that appear, like that which has been done for riscv64 and loong64 quite often these last few years. Removing architectures in existing packages: [...] This approach looks good. As I said, I'd rather only go this way if the maintainer in question notices that there is a need to do so. I agree that if it turns out that for a package to be removed there are reverse dependencies outside of Debian Med's maintainership which would be affected, we would need to coordinate with the maintainers of these reverse dependencies. My gut feeling says these cases will be exceptional though. I think it could also make sense to think of what to do for other architectures that are not yet covered in Michael's proposal, such as (subjectively) obscure archs that still are considered official release architectures (riscv64, mips64el, ...) or all the non-official architectures (alpha, hurd-*, m68k, ...)? For non-official archs within the context of Debian-Med, I just ignore them unless a simple patch is provided in BTS. They don't block migration to testing, so I don't think about them. Cheers Sascha OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages
On 28/03/2024 14.51, Michael R. Crusoe wrote: Dear colleagues and users, [snip] Fweh, that's a long email. Please do share your feedback here and on the Debian-Med Matrix channel for instant discussions: https://app.element.io/#/room/#debian-med:matrix.org Thank you all for the thoughtful and helpful replies! I will reply to some of your messages now and later I will open a merge request to the policy document later with specific text taking the feedback into account. I'll post the link here and we can continue to discuss the details. -- Michael R. Crusoe OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages
Hi, Am Mon, Apr 01, 2024 at 09:12:49PM +0200 schrieb Sascha Steinbiss: > > > If there is agreement with this, then I would like an amend the > > Debain-Med team policy to make it clear that we, as a community of > > package maintainers and users, are okay with removing support for 32-bit > > and/or big-endian systems without discussion. > > I'd probably not go as far as to eagerly _remove_ all support for 32-bit > as in RM'ing existing packages that still build and work fine. ACK. Finally also removing packages creates some work we finally want to save. I think we should simply apply this policy to new packages and those who start failing for whatever reason with no obvious fix / patch provided. > I know that many others in Debian care about their specific niche > architecture and would be offended at some random maintainer just > dismissing their subjectively reasonable request to fix things. Making > it known beforehand where Debian Med puts its focus would help in making > such situations feel less personal. Fully ACK. > > New packages that aren't "Architecture: all": 1. Add > > "architecture-is-64-bit" and "architecture-is-little-endian" to the > > "Build-Depends" list in "debian/control". > > Nice, didn't know about these virtual packages before. Makes sense for > new packages -- would this result in an equivalent effect as restricting > the "Architecture" list in all binary packages? If we agree about the policy to restrict new packages to the said architectures I'd recommend adding this to our package template[1]. > > Removing architectures in existing packages: > [...] > > This approach looks good. As I said, I'd rather only go this way if the > maintainer in question notices that there is a need to do so. > > I agree that if it turns out that for a package to be removed there are > reverse dependencies outside of Debian Med's maintainership which would > be affected, we would need to coordinate with the maintainers of these > reverse dependencies. My gut feeling says these cases will be > exceptional though. Sure. > I think it could also make sense to think of what to do for other > architectures that are not yet covered in Michael's proposal, such as > (subjectively) obscure archs that still are considered official release > architectures (riscv64, mips64el, ...) or As long as these do not create any trouble its perfectly fine to support these. > all the non-official architectures > (alpha, hurd-*, m68k, ...)? Hurd will be available next year. ;-P Kind regards Andreas. [1] https://salsa.debian.org/med-team/community/package_template/-/blob/master/debian/control?ref_type=heads -- https://fam-tille.de
Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages
Hi all, first of all thanks Michael for this idea and also for the elaborate proposal email that outlines the intended way to go quite well. [...] Support Debian-Med packages for 32-bit and/or big-endian architectures is not a good use of our limited resources. Agreed. [...] However, I think it is okay if an individual Debian-Med maintainer wishes to support extra architectures, especially if upstream is supportive. Also, agreed. I am very likely not that maintainer. Various times already I have been struck by bug reports and failing builds for release platforms that are probably irrelevant for most users of the affected software. I pushed through to fix the issue while knowing that the typical user would not be using this specific software on, say, s390x or a Raspberry Pi. Yes, I am aware that having all that variety at our fingertips promotes experimentation, but does that really justify the extra effort? But if that maintainer can't keep up, and the package is causing problems for other Debian-Med packages, then we should be okay with removing the extra architectures again. ACK. If there is agreement with this, then I would like an amend the Debain-Med team policy to make it clear that we, as a community of package maintainers and users, are okay with removing support for 32-bit and/or big-endian systems without discussion. I'd probably not go as far as to eagerly _remove_ all support for 32-bit as in RM'ing existing packages that still build and work fine. I'd rather like to see such a policy change to illustrate a common position that we'd rather disable an architecture and RM its binaries rather than fix a non-trivial issue on that platform, which might block a testing transition or cause some other roadblocks for the archs we actually care about. I know that many others in Debian care about their specific niche architecture and would be offended at some random maintainer just dismissing their subjectively reasonable request to fix things. Making it known beforehand where Debian Med puts its focus would help in making such situations feel less personal. How to make implement this policy with the tools available to us in 2024. New packages that aren't "Architecture: all": 1. Add "architecture-is-64-bit" and "architecture-is-little-endian" to the "Build-Depends" list in "debian/control". Nice, didn't know about these virtual packages before. Makes sense for new packages -- would this result in an equivalent effect as restricting the "Architecture" list in all binary packages? Removing architectures in existing packages: [...] This approach looks good. As I said, I'd rather only go this way if the maintainer in question notices that there is a need to do so. I agree that if it turns out that for a package to be removed there are reverse dependencies outside of Debian Med's maintainership which would be affected, we would need to coordinate with the maintainers of these reverse dependencies. My gut feeling says these cases will be exceptional though. I think it could also make sense to think of what to do for other architectures that are not yet covered in Michael's proposal, such as (subjectively) obscure archs that still are considered official release architectures (riscv64, mips64el, ...) or all the non-official architectures (alpha, hurd-*, m68k, ...)? Cheers Sascha OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages
On Thu, 2024-03-28 at 14:51 +0100, Michael R. Crusoe wrote: > > Like all policy proposals, this is not meant to be a hard rule for > all time. We can and should revisit the issue later! What do you think of the policy being instead of "-med team packages MUST support all current Debian architectures", "-med team packages (CAN or SHOULD) try to support all current Debian architectures." Many packages do work fine, but some make no sense without being able to access much more than 4G of memory or have picky CPU architecture dependencies. I don't think the team should automatically turn off all more obscure architectures, but it seems very reasonable to be quite willing disable builds for things that cause problems outside of x86_64/arm64. Diane signature.asc Description: This is a digitally signed message part
Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages
On Thursday, March 28, 2024 8:51:01 A.M. CDT Michael R. Crusoe wrote: > Therefore I personally conclude that: > Support Debian-Med packages for 32-bit and/or big-endian architectures is > not a good use of our limited resources. I've used that as a personal policy for years. In my case, I restrict the architecture set ONLY when maintaining all architectures becomes a burden. So far it has happened only in one package (ITK), and its downstream dependencies. I am left with a question whether that is what you are proposing, or whether you mean to preemptively restrict the architectures even when they are not troublesome? I would support the former but the latter position seems unwarranted to me. > Like all policy proposals, this is not meant to be a hard rule for all time. > We can and should revisit the issue later! Absolutely. The working set of machines does change over time as you mention yourself. I remember doing neuroinformatics research coding on SGI IRIX machines -- which will surely date me. :-) -Steve signature.asc Description: This is a digitally signed message part.
Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages
Hello, On 2024-03-29 06:43, Nilesh Patra wrote:> There are also packages inside debian med umbrella which are not necessarily related to medicine or bioinformatics. These include some general purpose python packages, some C/C++ libraries et. al. There are packages that reverse-depend on the same. I don't think it's a good idea to remove 32 bit support in *all* the packages that are under our umbrella, but probably only the ones that are end-user applications. It may be good to move packages not related to medicine to different teams over time but some of them actually don't fit into any availability team as per my understanding and may have to be moved to debian/ namespace. I think Nilesh raises very important points. Personally I see no problem in leaving arch:any in debian/control and from time to time RMing the failing architectures. Best wishes, Andrius
Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages
Hi Charles, Am Fri, Mar 29, 2024 at 03:48:07PM +0900 schrieb Charles Plessy: > > For the moment it would be easy to make sure at least new r-bioc-* > > packages are restricted to the said architectures by adding this to > > dh-r. > > I fully agree. I've pushed an (only weakly tested) patch to dh-r[1] implementing this. If you think this is fine, feel free to upload a new version of dh-r which enables wider testing. > By the way the next Bioconductor is scheduled for May 1st, shortly after > the R 4.4 release. Thanks for the information. I'd be super happy if this would be managed without my help in case I might become elected as DPL. I'm willing to take part but I have no idea how much my Debian time will be occupied. Kind regards Andreas. [1] https://salsa.debian.org/r-pkg-team/dh-r/-/commit/72571478f4bc889675a60a9a05d7ef31e8bbba15 -- https://fam-tille.de
irc #debian-med and #debian-med:matrix.org (was: Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages)
Hi, On Fri, Mar 29, 2024 at 07:21:27AM +0100, Andreas Tille wrote: > Am Fri, Mar 29, 2024 at 10:13:40AM +0530 schrieb Nilesh Patra: > > On 28 March 2024 7:21:01 pm IST, "Michael R. Crusoe" > > wrote: > > >and on the Debian-Med Matrix channel for instant discussions: > > >https://app.element.io/#/room/#debian-med:matrix.org > > > > I'll be happy to open another thread about it, but while we are at it, do > > you think it makes sense to make this as our official communication media? > > > > Most of us don't hang out on #debian-med IRC and it would be a little > > misleading for someone wanting to contact us. > > From my perspective the main drawpack of IRC is that you can't search in > history. What about setting the title of #debian-med IRC pointing to > our matrix channel? This would make easily clear what we prefered as > communication channel. > > > Should we just close the IRC channel and endorse the matrix channel as the > > official one? > > I do not use it but it makes sense to ask on IRC whether people > like this channel for whatever reason. FWIW, currently the title of the #debian-med IRC channel _does_ point to matrix: пет 29 09:54 -!- Topic for #debian-med: Find us now at https://app.element.io/#/room/#debian-med:matrix.org ! пет 29 09:54 -!- Topic set by ChanServ [servi...@services.oftc.net] [Wed Dec 21 01:54:21 2022] And: пет 29 09:54 [Users #debian-med] пет 29 09:54 [ azeem ] [ FloodServ ] [ matrix_ds ] [ tarzeau_ ] пет 29 09:54 [ charojovi[m] ] [ hlieberman] [ pabs] [ tassia ] пет 29 09:54 [ crusoe] [ joostvb ] [ pere] [ utkarsh2102] пет 29 09:54 [ dr-hax[m] ] [ KGB ] [ sanjkrsna[m]] [ yoh] пет 29 09:54 [ emollier ] [ KGB-2 ] [ satta ] пет 29 09:54 [ felipegmaia419] [ mapreri ] [ sivoais ] пет 29 09:54 -!- Irssi: #debian-med: Total of 22 nicks [0 ops, 0 halfops, 0 voices, 22 normal] пет 29 09:54 -!- Channel #debian-med created Mon Aug 20 03:47:08 2012 пет 29 09:54 -!- Irssi: Join to #debian-med was synced in 1 secs пет 29 09:54 -ChanServ(servi...@services.oftc.net)- [#debian-med] Welcome to Debian-Med -- enjoy Free Software! HTH, Bye, Joost
Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages
Le Fri, Mar 29, 2024 at 07:21:27AM +0100, Andreas Tille a écrit : > > For the moment it would be easy to make sure at least new r-bioc-* > packages are restricted to the said architectures by adding this to > dh-r. I fully agree. By the way the next Bioconductor is scheduled for May 1st, shortly after the R 4.4 release. Have a nice day, Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from home https://framapiaf.org/@charles_plessy - You do not have my permission to use this email to train an AI -
Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages
Hi, I'm personally fine with Michaels suggestion in general. Am Fri, Mar 29, 2024 at 10:13:40AM +0530 schrieb Nilesh Patra: > > > On 28 March 2024 7:21:01 pm IST, "Michael R. Crusoe" > wrote: > > There are also packages inside debian med umbrella which are not necessarily > related to medicine or bioinformatics. These include some general purpose > python packages, some C/C++ libraries et. al. There are packages that > reverse-depend on the same. I don't think it's a good idea to remove 32 bit > support in *all* the packages that are under our umbrella, but probably only > the ones that are end-user applications. When reading Michaels proposal I also was thinking about generic libraries we are packaging as pre-dependencies for our end-user applications. I'd be fine with mentioning those as exceptions from what I consider perfectly sensible for the packages that are really targeting at our user base. > It may be good to move packages not related to medicine to different teams > over time but some of them actually don't fit into any availability team as > per my understanding and may have to be moved to debian/ namespace. > > What do you think? I'm not convinced that moving package out of our focus is a good idea. When we did so in the past these packages somehow went out of our focus and we hear back from them only by testing removal warnings. I have no problem with moving packages if there is some request from somewhere else and thus there is some convincing interest that the package is maintained properly. But I would not browse the packages maintained by our team, check which might be of general interest, seek in what other team it might be appropriate, become a member of that team and maybe learn that this team has quite a different policy than we have (as I learned in DPT recently). In short: Keep on maintaining what we have and apply common sense where to restrict the architectures sensibly. BTW. actively restricting the architectures for existing packages just creates work for no use. I think we should simply focus on new packages and those that create some troublesome bug reports that we can deal with by removing unused architectures. One other hint: I consider it a good idea to forward our proposed change of policy to debian-devel@l.d.o (once we agreed upon the change - maybe in some MR) for two reasons: 1. There might be a chance we have overlooked something. 2. There might be other teams that are interested in a similar change of policy. > >and on the Debian-Med Matrix channel for instant discussions: > >https://app.element.io/#/room/#debian-med:matrix.org > > I'll be happy to open another thread about it, but while we are at it, do you > think it makes sense to make this as our official communication media? > > Most of us don't hang out on #debian-med IRC and it would be a little > misleading for someone wanting to contact us. >From my perspective the main drawpack of IRC is that you can't search in history. What about setting the title of #debian-med IRC pointing to our matrix channel? This would make easily clear what we prefered as communication channel. > Should we just close the IRC channel and endorse the matrix channel as the > official one? I do not use it but it makes sense to ask on IRC whether people like this channel for whatever reason. BTW, the Debian Med team is maintaining lots of packages in R pkg team - most prominently r-bioc-* packages but there are more packages dedicated to our user base. We should probably also write a R pkg policy (which is long overdue). For the moment it would be easy to make sure at least new r-bioc-* packages are restricted to the said architectures by adding this to dh-r. Kind regards Andreas. -- https://fam-tille.de
Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages
On 28 March 2024 7:21:01 pm IST, "Michael R. Crusoe" wrote: >Alas this is an involved process. If we have to do it a lot, it would be nice >if someone writes a tool to automate any aspect of the above! > >--- > >Fweh, that's a long email. Please do share your feedback here There are also packages inside debian med umbrella which are not necessarily related to medicine or bioinformatics. These include some general purpose python packages, some C/C++ libraries et. al. There are packages that reverse-depend on the same. I don't think it's a good idea to remove 32 bit support in *all* the packages that are under our umbrella, but probably only the ones that are end-user applications. It may be good to move packages not related to medicine to different teams over time but some of them actually don't fit into any availability team as per my understanding and may have to be moved to debian/ namespace. What do you think? >and on the Debian-Med Matrix channel for instant discussions: >https://app.element.io/#/room/#debian-med:matrix.org I'll be happy to open another thread about it, but while we are at it, do you think it makes sense to make this as our official communication media? Most of us don't hang out on #debian-med IRC and it would be a little misleading for someone wanting to contact us. Should we just close the IRC channel and endorse the matrix channel as the official one? Thanks, Nilesh
Debian-Med policy proposal: 64-bit & little-endian only* for new packages
Dear colleagues and users, I would like to propose a change to the Debian-Med team policy: https://med-team.pages.debian.net/policy/ Given that: 1. The package maintainers in the Debian-Med community are volunteers, and all of us have many other demands of our time 2. Debian-Med is targeting the use cases of "medical practice and research". 3. Medical institutions and researchers are almost entirely running on amd64 and arm64 systems. 4. The upstream maintainers of the tools and libraries packaged in Debian-Med are themselves almost entirely volunteers, or if they are maintaining scientific FOSS projects as part of their work then they have academic jobs. 5. There is no tradition of big-endian computing in the biomedical and life sciences. Therefore I personally conclude that: Support Debian-Med packages for 32-bit and/or big-endian architectures is not a good use of our limited resources. (Of course, if the package can only support a subset of the 64-bit+little-endian architectures, that is also acceptable.) However, I think it is okay if an individual Debian-Med maintainer wishes to support extra architectures, especially if upstream is supportive. But if that maintainer can't keep up, and the package is causing problems for other Debian-Med packages, then we should be okay with removing the extra architectures again. If there is agreement with this, then I would like an amend the Debain-Med team policy to make it clear that we, as a community of package maintainers and users, are okay with removing support for 32-bit and/or big-endian systems without discussion. Like all policy proposals, this is not meant to be a hard rule for all time. We can and should revisit the issue later! --- Personal thoughts on Debian's history of bringing up new architectures: 1. This is an aspect of Debian I find to be really impressive! I'm very grateful for it, and I have seen how other packaging systems struggle when they have to add a new architecture for the first time. 2. Note that this policy proposal is not "only amd64" or "only amd64 and arm64". I think supporting new architectures is important to avoid vendor lock-in and provide portability to the future. For example, I hope to see riscv64 HPC and personal computing become popular with researchers, software engineers, and (eventually) the public. 3. I still support adding in compatibility for non-amd64/arm64 to scientific software; especially if SIMD usage is responsible. But I don't think we should make it a team policy that doing such work is required. --- How to make implement this policy with the tools available to us in 2024. New packages that aren't "Architecture: all": 1. Add "architecture-is-64-bit" and "architecture-is-little-endian" to the "Build-Depends" list in "debian/control". Removing architectures in existing packages: 1. Check which reverse-dependencies would also need removal (below is adapted from https://wiki.debian.org/ftpmaster_Removals#Before_requesting_removal ) Debian Developers can run `ssh mirror.ftp-master.debian.org "dak rm --architecture=armel,armhf,i386 --binary-only --partial --rdep-check --no-action $SOURCEPACKAGE"`. I don't know of an alternative for non-DDs, sorry. If any of the reverse-dependencies are not Debian-Med packages (and have successfully built on the affected architectures) then you must get the approval of those maintainers before proceeding. However, that could be a sign that the package should move out from Debian-Med to another team, like Debian-Science, or something non-research/science related. A good example of this is the zstd package, first packaged for Debian-Med in 2015 by Kevin Murray; "libzstd1" now has over 2300 reverse-dependencies! The package "graduated" from Debian Med in 2022 and now maintained by the RPM team 2. Add "architecture-is-64-bit" and "architecture-is-little-endian" to the "Build-Depends" list in "debian/control" and upload a new version of the package to "UNSTABLE". 3. Repeat #2 for each of the affected Debian-med reverse-dependencies (and coordinate with any other maintainers as needed) 4. `reportbug ftp.debian.org` to request a "ROM Package removal - Request Of Maintainer." and list the official architectures to remove the binary packages of: typically that would be "armel armhf i386 s390x". 5. Repeat #4 for each of the affected Debian-med reverse-dependencies. Coordinate with the other maintainers to do the same. 6. Help the FTP team by marking which removal bug block which dependency. 7. Wait for the packages to be removed and the new uploads to migrate to testing, responding to any queries from the FTP team. Alas this is an involved process. If we have to do it a lot, it would be nice if someone writes a tool to automate any aspect of the above! --- Fweh, that's a long email. Please do share your feedback here and on the Debian-Med Matrix channel for instant discussions:
