how to convey package porting details?
Hi all, There are lots of packages that need porting to every new architecture that comes along. There are others that don't require porting but benefit in some way from porting to some aspect of the architecture. In order to help porters to prioritise those packages and quickly add support for their architecture, it would be nice to have a standard mechanism for source packages to indicate that they potentially require porting for each new architecture, the nature of the porting required and where in the source package the changes are required. For example packages like autotools-dev, linux, gcc or linuxinfo could state that they require porting to all new arches and have a pointer to Debian and or upstream porting info. Packages containing a JIT but with interpreter fallback could list themselves as having optional porting. Once we have a mechanism for this, the documentation for creating new Debian ports could provide a way to find the list of packages that need porter attention; via codesearch.d.n, apt, apt-file, grep-available etc. https://wiki.debian.org/PortsDocs/New -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: how to convey package porting details?
I like this idea. I would personally recommend adding negative priority as well. You know, it is completely meaningless to port some high performance scientific computing software to archs like armel... Meanwhile, different packages varies in the difficulty to port as well. A software that heavily leverages architecture specific intrisics is not likely easy to port. Packages that does not require hardware performance, and simply misses several arch-specific C macros should be easy to port. Since package maintainers should have somehow skimmed the whole codebase, they could provide an accurate hint about this, as long as such hints are useful for porters. On Mon, 2022-06-06 at 10:02 +0800, Paul Wise wrote: > > There are lots of packages that need porting to every new architecture > that comes along. There are others that don't require porting but > benefit in some way from porting to some aspect of the architecture. > > In order to help porters to prioritise those packages and quickly add > support for their architecture, it would be nice to have a standard > mechanism for source packages to indicate that they potentially require > porting for each new architecture, the nature of the porting required > and where in the source package the changes are required. > > For example packages like autotools-dev, linux, gcc or linuxinfo could > state that they require porting to all new arches and have a pointer to > Debian and or upstream porting info. Packages containing a JIT but with > interpreter fallback could list themselves as having optional porting. > > Once we have a mechanism for this, the documentation for creating new > Debian ports could provide a way to find the list of packages that need > porter attention; via codesearch.d.n, apt, apt-file, grep-available etc. > > https://wiki.debian.org/PortsDocs/New >
Bug#1012384: ITP: libtext-balanced-perl -- Perl module for extraction of delimited text from strings
Package: wnpp
Severity: wishlist
Owner: Ed J
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: libtext-balanced-perl
Version : 2.06
Upstream Author : Damian Conway
* URL : https://metacpan.org/pod/Text::Balanced
* License : GPL, Artistic, available at *
/usr/share/common-licenses/{GPL,Artistic}
Programming Lang: Perl
Description : Perl module for extraction of delimited text from strings
Text::Balances provides various extract_... subroutines may be used to
extract a delimited substring, possibly after skipping a specified prefix
string. By default, that prefix is optional whitespace (/\s*/), but can be
changed.
