Conversation

Notices

1. Embed this notice
   anna (navi@social.vlhl.dev)'s status on Wednesday, 07-May-2025 21:42:44 JST anna

   • PrivateGER :blobcoffee:
   @privateger @ari
   
   as a distro having to patch every single individual package because a library got a major security vuln (or build issue) but packages have a stupid lockfile that freezes an old version, is not fun
   
   and for a factual example, rust 1.80 broke api, which makes a few crates (more notably, the `time` crate) fail to build, and gentoo had to, manually track every single package using those now-broken crates, and patch *all* of them one by one
   
   in a c ecosystem, we'd update the package for `time`, and be done with it. this was just a build failure, now imagine if it was a major security issue, patching every user of a library with a new cve would be *hell*
   
   for more, read https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packagers-security-nightmare/
   
   --
   
   and in another note, if you even want a decent gui toolkit, if applications were to vendor that, *fun* having 52 copies of the massive gui code eating up my disk!
   • Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     anna (navi@social.vlhl.dev)'s status on Wednesday, 07-May-2025 21:42:42 JST anna

     in reply to

     • PrivateGER :blobcoffee:
     • [GRLC] (⁠^⁠.⁠_⁠.⁠^⁠)⁠ﾉ :neocat_flag_sapphic:
     @novenary @ari @privateger
     
     because rust dep graphs are gigantic
     and cargo is actively unfriendly about doing local libraries, as you can't precompile an rlib and use it as a static library system wide, and if you want to build a local index for source install, there's so much manual boilerplate and finicky setup
     *and* it still involves patching out the lockfiles because, while cargo-install ignores the lockfiles, cargo-build doesn't
     
     i personally worked on trying out per-crate packages for gentoo, it is a goal for us to do that because everything else will be less painful, but cargo actively makes that hell
     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     [GRLC] (⁠^⁠.⁠_⁠.⁠^⁠)⁠ﾉ :neocat_flag_sapphic: (novenary@akko.wtf)'s status on Wednesday, 07-May-2025 21:42:43 JST [GRLC] (⁠^⁠.⁠_⁠.⁠^⁠)⁠ﾉ :neocat_flag_sapphic:

     in reply to

     • PrivateGER :blobcoffee:
     @navi @ari @privateger yeah, using the lockfile for a distro package is a shortcut that a lot of distros are taking because the upfront investment is much lower, but it's a gigantic footgun precisely because of this
     the only correct way to solve this problem is to package libraries properly
     gentoo, arch and nixos are all taking this shortcut while they do it properly for python, idk if that's because python has smaller dependency trees or something?
   • Embed this notice
     anna (navi@social.vlhl.dev)'s status on Wednesday, 07-May-2025 21:46:53 JST anna

     in reply to

     • PrivateGER :blobcoffee:
     • [GRLC] (⁠^⁠.⁠_⁠.⁠^⁠)⁠ﾉ :neocat_flag_sapphic:
     @novenary @ari @privateger
     
     > Changes the path of the lockfile from the default (<workspace_root>/Cargo.lock) to PATH. PATH must end with Cargo.lock
     
     /dev/null seems like it already won't work (tho maybe if i set up an empty file? still setup but less ig), and, trying this right now:
     > error: the `--lockfile-path` flag is unstable, and only available on the nightly channel of Cargo, but this is the `stable` channel
     
     ...
     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     [GRLC] (⁠^⁠.⁠_⁠.⁠^⁠)⁠ﾉ :neocat_flag_sapphic: (novenary@akko.wtf)'s status on Wednesday, 07-May-2025 21:46:54 JST [GRLC] (⁠^⁠.⁠_⁠.⁠^⁠)⁠ﾉ :neocat_flag_sapphic:

     in reply to

     • PrivateGER :blobcoffee:
     @navi @ari @privateger precompiling rlibs doesn't sound like a good idea regardless, only the source code should be packaged and that's not difficult to automate at a basic level at least
     for library packages, removing the lockfile is unnecessary because only the top-level lockfile is ever considered, and there's a --lockfile-path argument which could be pointed to /dev/null
     
     I don't doubt you ran into issues but the problems are solvable, it's just a lot of work for a single person
   • Embed this notice
     anna (navi@social.vlhl.dev)'s status on Wednesday, 07-May-2025 22:29:24 JST anna

     in reply to

     • PrivateGER :blobcoffee:
     • [GRLC] (⁠^⁠.⁠_⁠.⁠^⁠)⁠ﾉ :neocat_flag_sapphic:
     @novenary @ari @privateger
     
     gentoo has eclass that define default functions, so i can remove the file at build time, and it's what i'm planning to do
     
     but first i need to solve the "install crate packages to a local index, and fill in index metadata in a way cargo doesn't cry about", and also "chromiumOS tried this but ended up with emerge spending 30 minutes on 'Resolving Dependencies'" (yes, this is portage being awful python software, but still, we need to fix it in order to do that)
     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     [GRLC] (⁠^⁠.⁠_⁠.⁠^⁠)⁠ﾉ :neocat_flag_sapphic: (novenary@akko.wtf)'s status on Wednesday, 07-May-2025 22:29:25 JST [GRLC] (⁠^⁠.⁠_⁠.⁠^⁠)⁠ﾉ :neocat_flag_sapphic:

     in reply to

     • PrivateGER :blobcoffee:
     @navi @ari @privateger oh, oof
     either way deleting the file at build time would work so this is largely a non-problem
     not sure what gentoo has in the way of generic build helpers, I know arch has none but for nixos there's a lot of language-specific infrastructure so you can say "build this rust application" and you don't have to repeat all the boilerplate, so this would plug right in