Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.maint.python > #13137

Re: Generic Python packages which don’t work on all architectures

From Ole Streicher <olebole@debian.org>
Newsgroups linux.debian.maint.python
Subject Re: Generic Python packages which don’t work on all architectures
Date 2021-01-22 10:00 +0100
Message-ID <BA0sp-7jk-3@gated-at.bofh.it> (permalink)
References (1 earlier) <BzxgJ-6DT-1@gated-at.bofh.it> <BzI2t-58c-1@gated-at.bofh.it> <BzIca-5ba-3@gated-at.bofh.it> <BzKnD-6np-5@gated-at.bofh.it> <BzRIt-2g9-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


Paul Wise <pabs@debian.org> 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 separate problem, and this IMO cannot be reliably
solved by adding a simple arch-specific declaration to the source
package: If we would do (require) f.e. an additional "installs-on" field
in d/control, then each maintainer would be requested to monitor all
dependencies on all archs to find out where the package could be
installable, and to re-upload the package with adjustments whenever one
of the dependencies changes the list of supported architectures.

IMO, a useful solution would be to parse the dependency chain on the
client (aptitude, synaptic or whatever) and to list only those packages
that can be installed.

If we would introduce arch specific marker packages, we wouldn't solve
this ofcourse, but we would solve the problem that you can install a
package that is actually not working on the architecture, which is even
a worse user experience. And we would solve the problem that one can't
specify f.e. all little-endian systems, or all 64-bit systems as build
dependency, except for explicitly listing all of them (which is IMO a
nightmare for ports or for derivatives that have additional
architectures).

It is not perfect, but a pragmatic step forward.

Best

Ole

Back to linux.debian.maint.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Generic Python packages which don’t work on all  architectures Stephen Kitt <skitt@debian.org> - 2021-01-20 20:50 +0100
  Re: Generic Python packages which don’t work on all architectures Matthias Klose <doko@debian.org> - 2021-01-20 21:10 +0100
  Re: Generic Python packages which don’t work on all architectures Paul Wise <pabs@debian.org> - 2021-01-21 02:50 +0100
    Re: Generic Python packages which don’t work on all architectures Christian Kastner <ckk@debian.org> - 2021-01-21 08:10 +0100
    Re: Generic Python packages which don’t work on all architectures Ole Streicher <olebole@debian.org> - 2021-01-21 14:20 +0100
      Re: Generic Python packages which don’t work on all architectures Paul Wise <pabs@debian.org> - 2021-01-21 14:30 +0100
        Re: Generic Python packages which don’t work on all architectures Ole Streicher <olebole@debian.org> - 2021-01-21 16:50 +0100
          Re: Generic Python packages which don’t work on all architectures Paul Wise <pabs@debian.org> - 2021-01-22 00:40 +0100
            Re: Generic Python packages which don’t work on all architectures Paul Wise <pabs@debian.org> - 2021-01-22 00:50 +0100
            Re: Generic Python packages which don’t work on all architectures Ole Streicher <olebole@debian.org> - 2021-01-22 10:00 +0100
      Re: Generic Python packages which don’t work on  all architectures Ansgar <ansgar@43-1.org> - 2021-01-21 14:40 +0100
        Re: Generic Python packages which don’t work on all architectures Ole Streicher <olebole@debian.org> - 2021-01-21 16:20 +0100

csiph-web