(please note that there’s a correction at the bottom) In the Overview of cross-architecture portability problems, I have dedicated a section to the problems resulting from use of 32-bit time_…
  • InverseParallax@lemmy.worldEnglish
    7·
    1 month ago

    This seems overblown, we’ve faced these things before.

    The straightforward path is adding new calls and structs and leaving the old code in place, then having tests that return -1 for time32_t and seeing what breaks.

    It’s not pretty, but this is life in the new epoch, gentoo doesn’t have it harder than anyone else except when they’re trying to rebuild while the transition is happening.

    I know nobody wants 2 apis, 1 deprecated, but this is an ancient design decision we have to live with, this is how we live with them.

  • yoevli@lemmy.worldEnglish
    4·
    1 month ago

    I’m not familiar with the specific install/upgrade process on Gentoo so maybe I’m missing something, but what’s wrong with forcing new installations to use time64 and then forcing existing installs to do some kind of offline migration from a live disk a decade or so down the line? I feel like it’s probably somewhat uncommon for an installation of any distro to be used continuously for that amount of time (at least in a desktop context), and if anyone could be expected to be able to handle a manual intervention like this, it’s long-time Gentoo users.

    The bonus of this would be that it wouldn’t be necessary to introduce a new lib* folder - the entire system either uses time64 or it doesn’t. Maybe this still wouldn’t be possible though depending on how source packages are distributed; like I said I dont really know Gentoo.

    • Aiwendil@lemmy.ml
      1·
      1 month ago

      I imagine the “update from another system” path runs in troubles with more complex gentoo installs than just the base system. For a full update from the live disk it will have to include lots and lots of (often exotic) tools that might be used in the building process (document generators like doxgen, lexer, testing frameworks, several build systems and make-likes. programming languages…) in addition to being able to build against the already installed updates for packages while not accidental building against packages that are not updated yet.

      Or you go the simpler way and only do a base update from the live-system…only update the base build system and package management of the gentoo system and afterwards boot in a “broken” system in which only the basics works and rebuild it from there.

      For be both those options sound less desirable than what is suggested in the blog.

  • BoringHusband@lemmy.world
    0·
    1 month ago

    Why would anyone be running a 32bit application in 2038? It is already hard enough now to continue 32bit support.