On 2024/04/21 08:45, Timo Myyrä wrote: > On Fri, Apr 19 2024, Sebastien Marie wrote: > > > (Adding Cc to stumpwm maintainer) > > > > Kirill A. Korinsky <kir...@korins.ky> writes: > > > >> Greetings, > >> > >> I've encountered an edge case with update of sbcl which lead to broken > >> stumpwm. > >> > >> My stumpwm configuration uses mpd modules which requires sb-bsd-sockets, so > >> after update of sbcl... it was broken. > >> > >> To overstep that issue I must rebuild stumpwm because it is saved image > >> which includes sbcl which was used when it was build. > >> > >> To avoid such issue in the future I suggest to add a note inside lang/sbcl > >> that after update x11/stumpwm should have increased revision. > >> > >> I haven't found any other port which depends on lang/sbcl. > > > > I commited a REVISION bump to x11/stumpwm (REVISION starts at 0). > > > > if I properly understand the problem, it is due that you are using both > > stumpwm (compiled with older sbcl compiler) and sbcl parts (for a mpd > > module), and the version mismatches. > > > > For now, bumping stumpwm is the simpler, but I wonder if it would be > > possible to use stumpwm somehow from source and let's sbcl compilation > > to refresh the fasl files if updated. Timo, any idea ? > > > > Thanks. > > I don't like the revision bump approach as why SBCL port should be > changed for each libraries/application using it. That being said, I do > not have anything better to offer here at the moment.
It's simple and means that users can verify that the binary on their system is the one from the downloaded package. And really if the compiler version changes, we'd like to make sure that users get updated binaries, so this seems a sane approach. Rather than REVISION it could use the SYSTEM_VERSION mechanism like we do with go or changes to the compiler in base, but while it's only 1 or a handful of ports using it, REVISION is simpler.
