Quoting plugwash (2022-06-27 03:11:42) > > On 27/06/2022 01:15, Jonas Smedegaard wrote: > > Thanks for clarifying. > > > > I consider it a *horrific* bug that an interface is explicitly > > advertised as available, linking against it succeeds, yet it is > > non-functional. > > > > In my opinion this renders the whole package unsuitable for release, and > > I hereby flag this bugreport as such. > > > > Please as a minimum ensure that broken or missing features are *not* > > advertised by the package. > > I'll remove the rustls support completely until/unless it can be > re-enabled in a sane form.
Please do. Bogusly advertising a feature not actually provided is what I find horrific here. With this change alone I find it sensible to lower severity of this bugreport back to "normal" (but that is just a suggestion: you as package maintainer has final say in how you treat bugreports for this package). > but lets be clear not every "feature" that exists in a rust crate > actually provides useful functionality. The "feature" > "rustls-native-certs" was never advertised as providing any particular > functionality. At this point I have only removed features, I have not > changed the functionality of any existing features. Depending on the > "feature" "rustls-native-certs" would be just as useless with the > unmodified upstream source as it would be with my patched version. Removing features but continue advertise them as offered (through package names containing "+") is what I consider horrific here. It is arguably correct that you didn't change any *code* but you patched Cargo.toml file to remove upstream-declared dependencies, causing builds to succeed that should have failed. > Assuming tokio-rustls and hyper-rustls are packaged, I do intend to > switch the "rustls-tls" feature from being an alias for > "rustls-tls-webpki-roots" to being an alias for > "rustls-tls-native-roots" in line with what I believe is appropriate for > Debian. Indeed I already have a patch in the package doing that, but the > feature is currently removed completely by a patch later in the series. I find it sensible that you choose to skip some features. I am not sure I find it sensible to *redefine* some features to mean something else that upstream, however. If you choose to do that, please consider making such strong deviation *very* clear - e.g. *both* document it in README.Debian and *also* mention it in long description. Let me try clarify my concerns here: I find it problematic generally is that Debian package deviates notably from upstream project without it being explicitly documented. By explicit documentation I don't mean changelog (and certainly not patch files installed next to code) but a README.Debian file. What I then find horrific here is that the vague deviation information hinted in virtual package names is not reliable. Please consider documenting deliberate deviation from upstream in README.Debian, in addition to ensuring that provided package names accurately reflects the features offered by the package. And please reconsider your proposed plan to change features to mean something different from what they are documented upstream to mean - especially when no Debian-specific documentation is offered! Thanks, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
