how on earth does openssh not only have incredibly fucked versioning but is the only package i've ever seen to mention a "privilege separation" chroot path which actively breaks non-root builds. are you fucking kidding me bruh. "privilege separation chroot" defaulting to /var/empty and it immediately errors if it can't create it????? why are your version strings like that bruh?????
241
Replies
·
0
Boosts
@SRAZKVT @c0dec0dec0de in fact, while modifications to different files being unrelated seems like a reasonable default, it is not in fact always or even often the case. if i modify the body of function f() and sarah has added a new call to f(), those changes are absolutely conflicting
@hipsterelectron @c0dec0dec0de no they aren't, unless something in the api of that function was modified
but yes merges can result in broken code, even if an automatic merge is succesful
@hipsterelectron @c0dec0dec0de but remember that these are context free merges, they do not know more than the content of the files, and they do not have any further information about the context in them (such as what kind of structure can be expected)
i believe that is an important property to hold, as otherwise you would be locked to the supported languages or tools, which is something i specifically do not want. a way of running ci on each commit to check it all still works should be sufficient to catch those errors
@SRAZKVT @c0dec0dec0de i was just thinking about the comment you made last weekend ish about automated API/ABI change detection. but that's not a property of the source files at all. your definition is exactly right
@hipsterelectron @c0dec0dec0de oh to me that should be in the build system / tests
@SRAZKVT @c0dec0dec0de 1000000%. especially since API/ABI change is very specifically calculated with reference to a version release
@SRAZKVT @c0dec0dec0de like, not necessarily semver or whatever, but it's a guarantee according to however your project has agreed to signal such changes to users, hopefully in the README or maybe something like STABILITY
@SRAZKVT OMG so i wanted to see if the rustc api stability lint somehow knew what semver was https://github.com/obi1kenobi/cargo-semver-checks/pull/1673 the FUBAR is fractal
@SRAZKVT so first off it's being added in a third-party linter which means definitionally it's heuristic and not a compiler analysis
- it uses stability markers parsed from rustdoc json output, not even by parsing the source code by hand as is done in every other rust linter, including this one
- yes the stability markers are unstable. yes there is a test that checks whether the stability markers are unstable.
- yes the stability markers all require a
since="..."version string argument provided as a literal string to the macro. yes, absolutely, you know it, the version string is completely ignored by all the semantic checks
@SRAZKVT oopsie! tee-hee! https://github.com/obi1kenobi/cargo-semver-checks/issues/1672 i did a buggie wuggie!
@SRAZKVT the reason i mention this is because i think there's a really interesting way to do long-term unstable traits
@SRAZKVT in particular, bumping an "implementation version" for the named feature. maybe it's a random hex string, maybe it's an incrementing integer, maybe the feature itself supports a distinct semver
@SRAZKVT the c preprocessor is absolutely appropriate for this. rust actually can't. and rustc would never go for it bc they obv get off on control. it could be done via autoconf without language support. but basically, semver as a guarantee for public APIs is completely independent from unstable, and furthermore unstable can be stable
