On Fri, 2022-03-25 at 23:34 +0100, Adam Borowski wrote:
> Suggestions?
FYI, as a result of this coming up on IRC again, I have summarised
various suggestions on this wiki page for future reference:
https://wiki.debian.org/InstructionSelection
Please feel free to update/fix the page as needed.
On Sun, 2022-04-03 at 14:17 +0300, Adrian Bunk wrote:
> For binaries, I have seen packages in the Debian Med (?) team that build
> several variants of a program and have a tiny wrapper program that chooses
> the correct one at startup.
It appears this is called simd-dispatch and the script is
On Wed, Apr 06, 2022 at 01:38:09PM +0200, Adam Borowski wrote:
> On Sun, Apr 03, 2022 at 02:17:15PM +0300, Adrian Bunk wrote:
> > On Fri, Mar 25, 2022 at 11:34:17PM +0100, Adam Borowski wrote:
> > > * while a hard Depends: works for leafy packages, on a library it
> > > disallows having
On Sun, Apr 03, 2022 at 02:17:15PM +0300, Adrian Bunk wrote:
> On Fri, Mar 25, 2022 at 11:34:17PM +0100, Adam Borowski wrote:
> > * while a hard Depends: works for leafy packages, on a library it
> > disallows having alternate implementations that don't need the
> > library in question. Eg,
On Sun, Apr 03, 2022 at 02:42:18PM +0200, Bastian Blank wrote:
> On Sun, Apr 03, 2022 at 02:17:15PM +0300, Adrian Bunk wrote:
> > SIMDe (or similar approaches) could be used to build variant(s) of the
> > library that have compile-time emulation of SIMD instructions in the
> > lower baseline
Bastian Blank writes:
> On Sun, Apr 03, 2022 at 02:17:15PM +0300, Adrian Bunk wrote:
>> SIMDe (or similar approaches) could be used to build variant(s) of the
>> library that have compile-time emulation of SIMD instructions in the
>> lower baseline builds of vectorscan.
>
> But why? Who in
On Sun, Apr 03, 2022 at 02:17:15PM +0300, Adrian Bunk wrote:
> SIMDe (or similar approaches) could be used to build variant(s) of the
> library that have compile-time emulation of SIMD instructions in the
> lower baseline builds of vectorscan.
But why? Who in their right mind would ever try to
On Fri, Mar 25, 2022 at 11:34:17PM +0100, Adam Borowski wrote:
> Hi!
Hi Adam!
>...
> * while a hard Depends: works for leafy packages, on a library it
> disallows having alternate implementations that don't need the
> library in question. Eg, libvectorscan5 blocks a program that
> uses it
On Sat, 2022-03-26 at 11:42 +0100, Stephan Lachnit wrote:
> On Sat, Mar 26, 2022 at 2:36 AM M. Zhou wrote:
> >
> > Indeed supporting number crunching programs on ancient
> > hardware is not meaningful, but the demand on Debian's
> > support for number crunching is not that strong according
> >
On Sat, 26 Mar 2022 at 09:43:32 +0800, Paul Wise wrote:
> It might be worth looking at how things like Steam and Flatpak/Snap
> solve this issue
In general they don't, or to put it another way, they "solve" it to the
same extent that Debian/apt/dpkg currently does. Each binary build has
a
On Sat, Mar 26, 2022 at 2:36 AM M. Zhou wrote:
>
> Indeed supporting number crunching programs on ancient
> hardware is not meaningful, but the demand on Debian's
> support for number crunching is not that strong according
> to my years of observation.
>
> For popular applications that can take
On Fri, Mar 25, 2022 at 11:34:17PM +0100, Adam Borowski wrote:
> While packages are allowed to not support entire architectures
> outright, there's a problem when some code requires a feature that is
> not present in the arch's baseline. Effectively, this punishes an arch
> for keeping
Adam Borowski wrote:
> * new installs fail quite late into installation process, leaving you
> with a bunch of packages unpacked but unconfigured; some apt
> frontends don't take this situation gracefully.
Maybe install isa-support by default and add an apt hook similar to the
apt-listbugs
Hi Adam,
I think the problems that apt/dpkg
are trying to deal with is already complicated enough, and
the architecture specific code are still not significant
enough to introduce change there.
Indeed supporting number crunching programs on ancient
hardware is not meaningful, but the demand on
Hi!
While packages are allowed to not support entire architectures
outright, there's a problem when some code requires a feature that is
not present in the arch's baseline. Effectively, this punishes an arch
for keeping compatibility. The package's maintainers are then required
to conform to the
15 matches
Mail list logo
