Github messages for voidlinux
 help / color / mirror / Atom feed
From: ahesford <ahesford@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: Re: [wip] common: disable creation of noarch packages.
Date: Thu, 20 Aug 2020 03:00:14 +0200	[thread overview]
Message-ID: <20200820010014.p_3g64iJzsjaVHcIqtC2gSijIcH83adB9eDXI2Jy3QU@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-24357@inbox.vuxu.org>

[-- Attachment #1: Type: text/plain, Size: 2172 bytes --]

New comment by ahesford on void-packages repository

https://github.com/void-linux/void-packages/pull/24357#issuecomment-676835665

Comment:
> I don't quite get what you mean. These other things are unnessecary, and the shorthand for `nodebug`, etc is useful for data packages. This is why I think we should rename it.

That a package is `noarch` implies that it has no native executables (which I am distinguishing from text files that are parsed by an interpreter and have an execute bit set). That a package has no native executables implies that we can set `nodebug` and `nostrip`. Transitively, `noarch` implies these things too, but if we're going to lop out the core functionality invoked by `noarch`, we shouldn't keep some vestigial keyword around just for convenience.

Keeping a `noarch` keyword without supporting `noarch` packages, where `noarch` is a wildcard for the package manager, is just misdirection. The right way to signal that we don't need to debug or strip anything is to add a `noexecutable` flag or something similarly named, or else just add the individual flags to templates. Calling it `noarch` is just going to lead to confusion, and keeping `archs=noarch` produces unexpected results because it has specific meaning now.

I haven't thought about package dependency graphs and don't much care to. In principle, it doesn't seem like properly supporting `noarch` in dependency resolution (and it seems to me the repo-maintenance challenges are just dependency resolution across the architecture dimension) should be too challenging, but I can certainly believe that difficulties in the implementation quickly become more trouble than they are worth to save some disk space.

If that's the case, drop `noarch` from XBPS, modify `xbps-src` to treat `archs=noarch` as `noexecutable=yes` and emit a warning about this transitional reinterpretation, modify `xlint` to complain when `arches=noarch` is detected and recommend the new keyword, and once we've rebuilt every `noarch` package with `noexecutable=yes` instead, drop these transitional modifications. Or just bite the bullet, migrate every template in one pass and be done with it.

  parent reply	other threads:[~2020-08-20  1:00 UTC|newest]

Thread overview: 89+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-19  6:51 [PR PATCH] " fosslinux
2020-08-19 12:23 ` ericonr
2020-08-19 12:38 ` ahesford
2020-08-19 12:46 ` ahesford
2020-08-19 13:03 ` Chocimier
2020-08-19 14:48 ` q66
2020-08-19 15:24 ` ahesford
2020-08-19 15:43 ` q66
2020-08-19 15:45 ` q66
2020-08-19 16:10 ` ahesford
2020-08-19 17:15 ` q66
2020-08-19 17:17 ` ericonr
2020-08-19 17:19 ` q66
2020-08-19 23:05 ` fosslinux
2020-08-19 23:10 ` fosslinux
2020-08-19 23:21 ` the-maldridge
2020-08-19 23:28 ` fosslinux
2020-08-19 23:30 ` the-maldridge
2020-08-20  0:24 ` q66
2020-08-20  0:38 ` fosslinux
2020-08-20  0:44 ` sgn
2020-08-20  0:44 ` sgn
2020-08-20  0:46 ` ericonr
2020-08-20  0:51 ` sgn
2020-08-20  0:56 ` fosslinux
2020-08-20  1:00 ` ahesford [this message]
2020-08-20  1:08 ` ericonr
2020-08-20  2:05 ` the-maldridge
2020-08-20  6:29 ` fosslinux
2020-08-20  6:32 ` fosslinux
2020-08-20 12:52 ` ericonr
2020-08-20 17:55 ` the-maldridge
2020-08-20 23:09 ` fosslinux
2020-08-21 22:26 ` [PR PATCH] [Updated] " fosslinux
2020-08-21 22:27 ` fosslinux
2020-08-21 22:29 ` [PR PATCH] [Updated] " fosslinux
2020-08-21 22:29 ` fosslinux
2020-08-24 23:49 ` fosslinux
2020-08-24 23:50 ` fosslinux
2020-08-24 23:50 ` fosslinux
2020-08-25 19:47 ` [PR REVIEW] " Chocimier
2020-08-25 19:49 ` Chocimier
2020-08-25 20:02 ` ericonr
2020-08-25 20:19 ` [PR REVIEW] " Chocimier
2020-08-25 22:55 ` fosslinux
2020-08-25 22:58 ` fosslinux
2020-08-27  7:22 ` [PR PATCH] [Updated] " fosslinux
2020-08-27  7:22 ` fosslinux
2020-08-27  7:23 ` fosslinux
2020-08-27 20:21 ` [PR REVIEW] " Chocimier
2020-08-27 20:28 ` Chocimier
2020-08-28  0:41 ` [PR REVIEW] " fosslinux
2020-08-28  0:43 ` fosslinux
2020-08-28  0:45 ` sgn
2020-08-28  1:07 ` fosslinux
2020-09-02  0:40 ` fosslinux
2020-09-02  0:40 ` fosslinux
2020-09-02  0:40 ` [PR REVIEW] " fosslinux
2020-09-03 23:47 ` fosslinux
2020-09-04 11:41 ` fosslinux
2020-09-04 11:44 ` fosslinux
2020-09-04 13:24 ` ahesford
2020-09-04 22:59 ` fosslinux
2020-09-04 23:17 ` fosslinux
2020-09-04 23:19 ` [PR PATCH] [Updated] " fosslinux
2020-09-04 23:19 ` [PR REVIEW] " fosslinux
2020-09-05  7:00 ` Chocimier
2020-09-05  7:16 ` fosslinux
2020-10-31  6:49 ` fosslinux
2020-10-31  6:49 ` fosslinux
2020-10-31  6:49 ` fosslinux
2020-10-31  6:49 ` fosslinux
2020-11-30 14:57 ` sgn
2020-11-30 16:37 ` sgn
2020-12-01 12:47 ` sgn
2020-12-05 10:17 ` sgn
2020-12-05 10:17 ` sgn
2020-12-15 11:26 ` fosslinux
2020-12-26  2:47 ` sgn
2020-12-26  2:48 ` sgn
2020-12-26  2:48 ` sgn
2020-12-26  2:48 ` sgn
2020-12-26  6:34 ` sgn
2020-12-26  6:42 ` sgn
2020-12-26 11:04 ` sgn
2020-12-26 11:04 ` sgn
2020-12-27 14:31 ` sgn
2021-01-20 12:34 ` [PR PATCH] [Closed]: " q66
2021-01-20 21:47 ` fosslinux

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200820010014.p_3g64iJzsjaVHcIqtC2gSijIcH83adB9eDXI2Jy3QU@z \
    --to=ahesford@users.noreply.github.com \
    --cc=ml@inbox.vuxu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).