Musl update

[motorto]

Hey everyone creating this discussion so that we can talk somewhere that is easier to follow up the discussion instead of #xbps irc channel.

Issues with updating musl currently:

• time_t change that breaks abi, for 32bit systems (i686,armv7l)

Been thinking on possible solutions ("workarounds") for musl update,

• The easier one revbump everything and job done (put all mirrors offline, until world rebuild is done)
• Desync the 32bits mirrors from the rest, where x86_64 would have package
  with rev 1, and 32 bits repos with rev 2. This would go away when a package gets
  updated again and both mirrors have the same version_revision again. In order
  to achieve this create a new field in all templates revisionTIME_T where
  revisionTIME_T > revision. The builders will need to be updated such that
  when they receive a package with revisionTIME_T > revision, only the
  32bits builders get activated. overtime this revisionTIME_T field would
  disappear from all templates.

Would like to know your opinions on this topic, your possible solutions and maybe issues that I failed to consider when updating the musl package.

[dkwo]

Since the ABI for 32-bit systems changes, we need a full rebuild of these repos. But xbps lacks support for enforcing that all installed packages are with the new ABI, i.e. reinstalling every package in an atomic way.

in other words, work on void-linux/xbps#331 :)

[CameronNemo]

It seems clear that the ABI PR is not getting traction, and continuing to distribute musl 1.1, four years after it was EOL'd, patched up with questionable CVE applicability and fix backporting, could be considering damaging to musl's brand.

My take: patch musl 1.2 to keep time_t the same size on 32 bit platforms. Ship it.

Another alternative is to just EOL 32bit time_t musl platforms and have users reinstall (or fix with a static xbps at their own peril). More disruptive for sure.

[ahesford]

I think our best bet is what you consider disruptive: drop arm*-musl and just move on. This simplifies our test matrix and reduces build loads at the expense of a small group of users.

[dkwo]

I second this. Can this be done at the infrastructure level, or how?

[ahesford]

Yank down the builders, remove all packages from the repo, profit.

[iFoundSilentHouse]

I have rpi of 1st gen which is armv6l and imho Void is not about experimenting with ancient arm hardware. Hardware like this doesn't need stable-rolling soft that Void provides because there too few people testing them. So I, as a daily user of armv6l vote for dropping arm*-musl for the sake of fresh x86_64, aarch64 musl support