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

"Michael R. Crusoe" <[email protected]> Sat, 6 Apr 2024 14:37:41 +0200
Newsgroups	gmane.linux.debian.devel.medical
Message-ID	<[email protected]>

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" <[email protected]> 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 [email protected] (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 (application/pgp-signature, 840 B)