[mkroot] [Aboriginal] Migrating aboriginal->mkroot list.

[Rob Landley]

On 02/21/2018 04:31 PM, Alain Toussaint wrote:
> Le mercredi 21 février 2018 à 16:25 -0600, Rob Landley a écrit :
>> I'm going to try to get a second mkroot release out this weekend, and as part of
>> that I'm shutting down the old aboriginal list and migrating the subscribers
>> here to the mkroot list.
> 
> Go right ahead :)
> 
>>
>>   https://twitter.com/landley/status/964620648050982912
>>
> 
> <scratch head> No big issue here, I've been on gcc 7+ (LFS-SVN) for over a year and a half.</scratch
> head>

Did you see the "arm requires perl again", "x86-64 doesn't build without
libtool" bits earlier in that twitter thread? The kernel is growing dependencies
faster than I've had a chance to go in and trim them. :(

The comment at the end about toolchains is because I defended the 4.2.1
toolchain for a long time, ala
https://github.com/landley/aboriginal/blob/master/sources/patches/linux-hack.patch
and
https://github.com/landley/aboriginal/blob/master/sources/patches/gcc-core-macrosity.patch
and
https://github.com/landley/aboriginal/blob/master/sources/patches/linux-fixsh4.patch
and so on.

When you _stop_ defending this sort of thing, problems accumulate. Bit rot is a
real thing when one half an interface changes and the other doesn't and there's
no regression testing, the old code no longer works in the new environment. It
could be an API subtly changing, a tool that processes input data to produce
output data having the input _or_ output formats change, or you could have a
tool/api/format get replaced by a different one and the world migrating en masse
so your old code no longer _applies_. And of course there's the problem of
basically the same (or equivalent) code accumulating new "required" dependencies
that your environment doesn't have/want. (I.E. "The systemd problem.")

Rob