Arch Linux

Alternatively add --enable-install-program=arch to the configure call in the coreutils PKGBUILD so arch will be installed / provided by coreutils.
Edit:
https://github.com/dracutdevs/dracut/pull/573 should resolve the issue.

There has been no activity on those github issues replacing the usage of arch with uname. I'm not sure we need to enable this in coreutils, but I'm not inclined to maintaining these as patches, because quite frankly, if we don't have any kind of response from upstream (which has been the case so far), the dracut replacement is in jeopardy.

The specific patch which loqs linked to was submitted as a PR on May 22. It took until July 19, but it did get merged, it simply has not been tagged in a new release. So we could just cherry-pick that commit.

I make no comment about "general responsiveness".

...

I do agree there's no good reason to enable non-default, deprecated binaries just for software living in the past or on Debian.

I can certainly cherry pick that to easily fix this one. I'm not even sure when they'll make a new release. But on the general responsiveness front, I've never heard back from dracut's lead developer. I'm not sure they are interested in other distros. And for us to be able to fully run their tests we'll have to make a lot of changes to them, because right now they assume a red hat/fedora/centos environment for lots of things.

Maybe it's even better to use latest git snapshot instead of release as there are many more bugfixes there.

We package only the latest release of software. We can patch things to adapt them to Arch, as is this case, but other than that, I won't package a git version. I'm preparing a merged patch for all the instances of "arch".

There are many exceptions from this including such critical parts like glibc or systemd and others where upstream is release-averse. Here's latest example: https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/xdg-utils&id=7abeda2f127d5eb7032b328569d3b35ad0383ec9

This is just cost-benefit calculation.

That's simply completely and utterly untrue. The truth and reality of the situation is that, like many things, this is a situation where there are no "wonderful" solutions, and the workarounds as implemented don't make everyone happy and some people, in fact, hotly debate it. Sometimes people will hotly^2 debate it, or debate it at even greater exponential values. Ultimately, it is up to each individual maintainer to determine how much confidence they have in pulling from upstream master, and whether there is sufficient justification to do it anyway.

...

systemd and glibc are explicitly exceptions to this rule, as both of them are regularly building from either a tagged stable release or from the upstream designated "stable maintenance backports" branches, in the case of systemd, the actual repository we use for source code is even literally called https://github.com/systemd/systemd-stable ("Backports of patch from systemd git to stable distributions")

This code is only used in a very judicious manner, and only after upstream has done a cost-benefit analysis of the commits in question, then signed off on them as something suitable for downstream distributors to feel comfortable using with the same degree of confidence, stability, and compatibility as the base release from which they are forked.

For entirely understandable reasons, we have the utmost confidence that these commits are intended for distributions to use *in preference over* the actual release tags. These are LTS-worthy commits. Upstream has taken these commits and emblazoned "please backport these into your LTS distro", in neon lights.

These two packages are a very bad example of "critical parts where upstream is release-averse". (This is besides for the fact that both upstreams are not, in fact, release-averse at all. They release new feature releases all the time. glibc's homepage even says "The GNU C Library releases every 6 months." Explain how that is release-averse when I can predict the month that they will release every new version for the next 60 years?)

"That's simply completely and utterly untrue. ... Ultimately, it is up to each individual maintainer to determine how much confidence they have in pulling from upstream master, and whether there is sufficient justification to do it anyway."

So you claim what I wrote is untrue and then repeated my point that it's up to maintainer to decide???

I have experience with maintaining glibc & systemd so I know very good their release practices. I also know that other upstreams usually just make stable point releases rather than expecting that downstream will follow every single commit they put in a stable branch which in reality means there is no distro which ships the same systemd & glibc version.

All of those details aren't important for this discussion though, I gave you perfect example of xdg-utils where Arch decided to follow git snapshot because of upstream release-aversion and you just ignored it because it's against your "completely and utterly untrue" narrative.

It is completely and utterly untrue that "There are many exceptions from this including such critical parts like glibc or systemd".

...

Aside: I hope and pray you don't consider xdg-utils to be critical. As a standard it's okay. As a collection of programs I've rarely met anyone who finds it pleasant to use. There are a long list of people who wrote their own versions from scratch because it was better than relying on xdg-open.

I will however acknowledge that xdg-utils (unlike dracut) is a project that can be optimistically described as "on life support". Even there, it is quite trivial to review the handful of bugfixes since the last release and decide it's safe to package, vs. YOLO pulling in significant changes from dracut master.

@grazzolini will you add upstream fix for that bug then?

@michel, yes, I'm cherry picking the fixes and releasing a package.

@grazzolini - I'm sorry for pinging you again but this still is not fixed.

Hi, I have backported the changes and released it in a new package.