Hacker News new | ask | show | jobs
by ariadneconill 1753 days ago
the only thing the proposed change does is encode something that is already factual: if you install that glibc package, you have a high likelihood of breaking your system.

it's not like we are blocking it in apk-tools, and you can roll your own musl package with the conflict removed by simply building it with the `ALLOW_GLIBC_PKG` option.

1 comments

It feels like you’re splitting hairs. No, you’re not blocking it in apk-tools, and yes, a user can work around the change you’re making to continue doing what they want. But your post directly says “I have also proposed an update to Alpine which will block the installation of the glibc packages produced by the alpine-glibc project”. So I’m not sure how describing it as “blocking this downstream project” could possibly be inaccurate.
I am proposing that we encode something that is already factually accurate: glibc and musl generally do not mix in any way that results in a stable system.

Do you not think that distributions should make even a little bit of effort to introduce friction toward scenarios known to break systems?

If apk-tools had a soft conflict option, where it printed a warning and required the user to acknowledge that warning somehow before continuing, that would also solve the issue as far as I am concerned, but it does not have such an option at this time, and we need to put our foot down sooner rather than later.

Edit: besides, nothing has been implemented. This is just one proposal, the point of having a conversation is to determine what the best option for solving this issue is.

The user already had to go out of their way to install it; I'm not sure adding an extra flag is a huge difference.
alpine exists in the open source space and must behave like an open source project.

You don't get to tell your users how to use your project.

That is the entire fucking point of open source software.

As visible upthread, I think starting w/ the block in code is a bad move, and am sad that reaching out to the maintainer of alpine-glibc seems like an afterthought.

That said, there is not a universal mandate for how an open source project “must behave”, other than that the terms of the license (which the authors of the code are able to choose). There isn’t a single cohesive “entire fucking point” of open source. The things proposed in the blog post are permissible under the license, are able to be bypassed by the user, and are not some earthshattering affront to human decency.

We should be able to disagree about the best course of action without falling into incendiary accusations.

I'm glad to know that free software maintainers exist to do whatever you want us to do, and that we don't get to set our own boundaries. Cool, cool.
> You don't get to tell your users how to use your project.

Sure I guess but "don't footgun yourself" is pretty different. But I guess some people just like using linux for the novelty of breaking shit and feeling smart about fixing it.