Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages

[Michael R. Crusoe]

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" <cru...@debian.org> 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