[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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" <crusoe@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.

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature


Reply to: