I.e., the current policy forbids the Rust’s community’s own development workflow!
only if you’re trying to read that into that policy. coming to the actual meat of the article:
Firstly, in practical terms, Debian may need to backport bugfixes, or sometimes other changes. Sometimes Debian will want to pre-apply bugfixes or changes that have been contributed by users, and are intended eventually to go upstream, but are not included upstream in official Rust yet. This is a routine activity for a distribution. The policy, however, forbids it.
A Debian+Rust version x.y.z that has backported bugfixes absent from the upstream version x.y.z sounds like a massive nightmare for crate authors who want to detect buggy versions and work around them. You’d think this is an unlikely scenario but it’s happened to me in the past that “software X [Debian’s version]” needed special handling in code. python/pip unbundling and python-requests unbundling to name a few. Spare me the lecture about how that is necessary for security, I plainly don’t care. in the end it’s all opinions and an inability to compromise from Debian’s side.
So: Good. I absolutely detest Debian’s way of packaging software while ignoring the wishes of upstream maintainers and I hope that this second Iceweasel-scenario finally puts a stop to it. Although I doubt it.
So: Good. I absolutely detest Debian’s way of packaging software while ignoring the wishes of upstream maintainers and I hope that this second Iceweasel-scenario finally puts a stop to it. Although I doubt it.
The practical consequence of this is that you are simply not going to have a well supported Rust package in Debian, this is going to be detrimental to the entire community.
as a crate maintainer who uses rustup, that is actually a preferrable scenario to me. if debian is unable to adapt then it shouldn’t be other people’s problems.
If you are a crate maintainer that uses rustup, then what Debian does has no bearing for your work. Rust is packaged to support the development and distribution of rust-based software in their package repositories.
The linked thread is mostly about Arch and discusses dynamic linking. I don’t see the relevance here.
*nod* Once I’ve migrated to things like Flathub for my “upstream blessed” distribution mechanisms, my plan is to include a notice on my bug trackers saying that all bugs must have been reproduced using the upstream-blessed builds and that any bugs which have not been must be reported to the package maintainer for your distribution channel for triage.
Interestingly, this was the traditional social contract between developers and packagers. Users would report their bugs to packagers first, and packagers would reproduce them against upstream and forward higher-quality reports to developers.
I think at some point we decided that it’s quicker to go directly to upstream, and quite reasonably so.
I’m very aware of the xscreensaver situation, and I don’t think it necessarily reflects well on Debian. However I don’t necessarily think it’s causing jwz a lot of extra work as the bugs reported are already fixed. I do understand getting emails about them is not nice.
my crates are part of rust-based software that will inevitably be packaged by debian. then, because debian patched up rust, it may trigger buggy behavior in those crates that would otherwise not be a problem. now i have to fix bugs that only occur on debian. this exact situation has already happened to me with Python. it will happen again, although maybe not to me.
the linked thread is not about arch: it’s about debian’s inability to package software without heavily modifying it (mostly unbundling). that’s very much relevant to the discussion of trademark policy.
my crates are part of rust-based software that will inevitably be packaged by debian. then, because debian patched up rust, it may trigger buggy behavior in those crates that would otherwise not be a problem. now i have to fix bugs that only occur on debian. this exact situation has already happened to me with Python. it will happen again, although maybe not to me.
Crates are packages by Debian to support the distribution of their binaries. You do not have to fix any bugs Debian introduces, as that is their problem alone.
the linked thread is not about arch: it’s about debian’s inability to package software without heavily modifying it (mostly unbundling). that’s very much relevant to the discussion of trademark policy.
The only mention of “Debian” is between you and me 2-3 years ago, which the link is not pointing at either. The discussion is also about dynamic versus static linking. I struggle to see the relevance.
People do expect to be able to build software with Debian’s compilers, and do complain to authors when this is “broken”.
I’ve received such reports myself.
Debian theoretically asks people to report to them first, but my software has my name on it, and my bug tracker is findable via my program’s name, so people report to me anyway.
This isn’t limited to Rust nor Debian. I’ve had complaints about crashes caused by outdated C compilers on other distros.
The trademark policy doesn’t prohibit redistribution – it just requires that the name be different in case of unreasonable modifications. One way to think of it is as a way to add further friction against users going directly to upstream.
The issue with claiming it’s “just a rename” is that you are dealing with programs and libraries that hardcode the binary names. This makes it non-trivial to rename anything in an existing ecosystem without making it worse for all parties involved.
rustup would need to be extensively patched to account for a new name, and so would any other supported tooling.
I would argue that that just accurately reflects the cost of forking a core library or piece of infrastructure, rename or not. It’s just that without the rename, the Debian project has mostly managed to externalize the cost of potential incompatibilities and dump the work on upstream.
It’s just that without the rename, Debian project has mostly managed to externalize the cost of potential incompatibilities and dump the work on upstream.
It’s important to realize that Debian is not telling people to go upstream. The users decide to do this themselves. As distro developers we are expected to reproduce issues and bring them forward instead of ushering users to upstreams.
I’m not saying that this is done intentionally by Debian, but that, because those are the de-facto dynamics (people go to upstream first), Debian (and other distros) has mostly managed to avert their eyes from this problem. And that’s how you get “but renaming comes with a cost” although the cost has already been paid elsewhere, by accident or not.
I’m not saying that this is done intentionally by Debian, but that, because those are the de-facto dynamics (people go to upstream first), Debian (and other distros) has mostly managed to avert their eyes from this problem.
Then I don’t think you know nor understand the Linux distro community very well? It’s a well known problem that extends beyond this particular Rust discussion.
only if you’re trying to read that into that policy. coming to the actual meat of the article:
A Debian+Rust version x.y.z that has backported bugfixes absent from the upstream version x.y.z sounds like a massive nightmare for crate authors who want to detect buggy versions and work around them. You’d think this is an unlikely scenario but it’s happened to me in the past that “software X [Debian’s version]” needed special handling in code. python/pip unbundling and python-requests unbundling to name a few. Spare me the lecture about how that is necessary for security, I plainly don’t care. in the end it’s all opinions and an inability to compromise from Debian’s side.
So: Good. I absolutely detest Debian’s way of packaging software while ignoring the wishes of upstream maintainers and I hope that this second Iceweasel-scenario finally puts a stop to it. Although I doubt it.
The practical consequence of this is that you are simply not going to have a well supported Rust package in Debian, this is going to be detrimental to the entire community.
as a crate maintainer who uses rustup, that is actually a preferrable scenario to me. if debian is unable to adapt then it shouldn’t be other people’s problems.
If you are a crate maintainer that uses
rustup, then what Debian does has no bearing for your work. Rust is packaged to support the development and distribution of rust-based software in their package repositories.The linked thread is mostly about Arch and discusses dynamic linking. I don’t see the relevance here.
First of all, I’m not saying that i agree with @unitaker that this policy is good, or even with the OP that this kind of thing violates the policy. However, I do want to point out that what Debian does can cause problems for upstream maintainers. https://www.jwz.org/blog/2016/04/i-would-like-debian-to-stop-shipping-xscreensaver/
*nod* Once I’ve migrated to things like Flathub for my “upstream blessed” distribution mechanisms, my plan is to include a notice on my bug trackers saying that all bugs must have been reproduced using the upstream-blessed builds and that any bugs which have not been must be reported to the package maintainer for your distribution channel for triage.
Downstreams are free to package my stuff if they want, but I refuse to take on extra work as a result of it. (The Weird architectures weren’t supported to begin with stance.)
Interestingly, this was the traditional social contract between developers and packagers. Users would report their bugs to packagers first, and packagers would reproduce them against upstream and forward higher-quality reports to developers.
I think at some point we decided that it’s quicker to go directly to upstream, and quite reasonably so.
I’m very aware of the xscreensaver situation, and I don’t think it necessarily reflects well on Debian. However I don’t necessarily think it’s causing jwz a lot of extra work as the bugs reported are already fixed. I do understand getting emails about them is not nice.
my crates are part of rust-based software that will inevitably be packaged by debian. then, because debian patched up rust, it may trigger buggy behavior in those crates that would otherwise not be a problem. now i have to fix bugs that only occur on debian. this exact situation has already happened to me with Python. it will happen again, although maybe not to me.
the linked thread is not about arch: it’s about debian’s inability to package software without heavily modifying it (mostly unbundling). that’s very much relevant to the discussion of trademark policy.
Crates are packages by Debian to support the distribution of their binaries. You do not have to fix any bugs Debian introduces, as that is their problem alone.
The only mention of “Debian” is between you and me 2-3 years ago, which the link is not pointing at either. The discussion is also about dynamic versus static linking. I struggle to see the relevance.
People do expect to be able to build software with Debian’s compilers, and do complain to authors when this is “broken”.
I’ve received such reports myself.
Debian theoretically asks people to report to them first, but my software has my name on it, and my bug tracker is findable via my program’s name, so people report to me anyway.
This isn’t limited to Rust nor Debian. I’ve had complaints about crashes caused by outdated C compilers on other distros.
The trademark policy doesn’t prohibit redistribution – it just requires that the name be different in case of unreasonable modifications. One way to think of it is as a way to add further friction against users going directly to upstream.
The issue with claiming it’s “just a rename” is that you are dealing with programs and libraries that hardcode the binary names. This makes it non-trivial to rename anything in an existing ecosystem without making it worse for all parties involved.
rustupwould need to be extensively patched to account for a new name, and so would any other supported tooling.I would argue that that just accurately reflects the cost of forking a core library or piece of infrastructure, rename or not. It’s just that without the rename, the Debian project has mostly managed to externalize the cost of potential incompatibilities and dump the work on upstream.
It’s important to realize that Debian is not telling people to go upstream. The users decide to do this themselves. As distro developers we are expected to reproduce issues and bring them forward instead of ushering users to upstreams.
I’m not saying that this is done intentionally by Debian, but that, because those are the de-facto dynamics (people go to upstream first), Debian (and other distros) has mostly managed to avert their eyes from this problem. And that’s how you get “but renaming comes with a cost” although the cost has already been paid elsewhere, by accident or not.
Then I don’t think you know nor understand the Linux distro community very well? It’s a well known problem that extends beyond this particular Rust discussion.