Path: csiph.com!aioe.org!bofh.it!news.nic.it!robomod From: Ole Streicher Newsgroups: linux.debian.maint.python Subject: Re: Generic Python packages which =?utf-8?Q?don=E2=80=99t?= work on all architectures Date: Fri, 22 Jan 2021 10:00:02 +0100 Message-ID: References: X-Mailbox-Line: From debian-python-request@lists.debian.org Fri Jan 22 08:54:09 2021 Old-Return-Path: X-Amavis-Spam-Status: No, score=-5.464 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, HEADER_FROM_DIFFERENT_DOMAINS=0.249, KHOP_HELO_FCRDNS=0.399, LDO_WHITELIST=-5, SARE_HEAD_8BIT_SPAM=0.888] autolearn=no autolearn_force=no X-Policyd-Weight: using cached result; rate: -5.5 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Lines: 34 X-Mailing-List: archive/latest/18913 List-ID: List-URL: List-Archive: https://lists.debian.org/msgid-search/87czxxgygv.fsf@burgos Approved: robomod@news.nic.it Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Date: Fri, 22 Jan 2021 09:36:16 +0100 X-Original-Message-ID: <87czxxgygv.fsf@burgos> X-Original-References: <20210120203941.1a41cc06@heffalump.sk2.org> <87zh12ihk6.fsf@burgos> <87im7qgvon.fsf@burgos> Xref: csiph.com linux.debian.maint.python:13137 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 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