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
>
Reply to: