Paul Wise writes:
> On Thu, Jan 21, 2021 at 3:42 PM Ole Streicher wrote:
>
>> But this is also the case for all packages which implicitly depend on
>> other packages which are not available on some architectures.
>
> This is true, but it doesn't make for a good user experience.
Yes, but this is a
On Thu, Jan 21, 2021 at 11:30 PM Paul Wise wrote:
> there is probably some coverage of arch:all packages on debci, not
> sure if it tests them on multiple arches though.
FTR, #debci says arch:all packages get tested on all debci arches.
--
bye,
pabs
https://wiki.debian.org/PaulWise
On Thu, Jan 21, 2021 at 3:42 PM Ole Streicher wrote:
> But this is also the case for all packages which implicitly depend on
> other packages which are not available on some architectures.
This is true, but it doesn't make for a good user experience.
> Generally, arch:all packages depend on a lo
Paul Wise writes:
> On Thu, Jan 21, 2021 at 1:12 PM Ole Streicher wrote:
>
>> This would be a quite flexible and extendible approach to have packages
>> installable only where they work.
>
> There is precedent for this sort of thing in the isa-support source
> package, which fails installation whe
Ansgar writes:
> On Thu, 2021-01-21 at 13:46 +0100, Ole Streicher wrote:
>> I am still wondering why we don't have just empty some pseudo-
> packages that are available only on specific architectures
>> (or groups of them, like linux, or little endian, or 64 bit or so).
>
> To solve which problem
On Thu, 2021-01-21 at 13:46 +0100, Ole Streicher wrote:
> I am still wondering why we don't have just empty some pseudo-
packages that are available only on specific architectures
> (or groups of them, like linux, or little endian, or 64 bit or so).
To solve which problem?
Packages being install
On Thu, Jan 21, 2021 at 1:12 PM Ole Streicher wrote:
> This would be a quite flexible and extendible approach to have packages
> installable only where they work.
There is precedent for this sort of thing in the isa-support source
package, which fails installation when your CPU doesn't support
pa
Paul Wise writes:
> This is what I eventually chose for iotop. At the time I wanted dpkg
> and dak to support something like Architecture: linux-all, which would
> build arch: all packages, but only put them in the Packages files for
> the Linux architectures.
>
> I am now thinking that a more gen
On 21.01.21 02:44, Paul Wise wrote:
> I am now thinking that a more generic solution than Architecture:
> linux-all is needed, in order to cover your case as well. Perhaps
> something like Available-Architecures or Runtime-Architectures or
> Architecture-all-Architectures: or similar.
To be honest
On Wed, Jan 20, 2021 at 7:40 PM Stephen Kitt wrote:
> I’ve come across a situation which doesn’t seem to be addressed by existing
> policies: the python-ptrace source package only ships
> architecture-independent content, but it works on a small number of
> architectures (currently, 32/64-bit x86,
On 1/20/21 8:39 PM, Stephen Kitt wrote:
> Hi,
>
> I’ve come across a situation which doesn’t seem to be addressed by existing
> policies: the python-ptrace source package only ships
> architecture-independent content, but it works on a small number of
> architectures (currently, 32/64-bit x86, 32-
Hi,
I’ve come across a situation which doesn’t seem to be addressed by existing
policies: the python-ptrace source package only ships
architecture-independent content, but it works on a small number of
architectures (currently, 32/64-bit x86, 32-bit ARM, 32/64-bit PPC).
As a result, the packages
12 matches
Mail list logo
