Hi Jonas,

Could you please add the librust-lazy-regex+$feature-dev packages to librust-lazy-regex-dev's
Provides in experimental? In order to complete the lazy-regex 2->3 transition [1] we would be
able to only touch two packages (modulo unrelated changes) [2] if you did. At this time, the
package only provides the librust-lazy-regex-3+$feature-dev packages, preventing its usage
as a build dependency (hence the important severity) to packages whose Cargo.toml has a
versioned dependency of the form 'lazy-regex = ">=2.x"'. A patch is in attachment.

Thank you!


[1] https://salsa.debian.org/rust-team/debcargo-conf/-/issues/85
[2] https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/768

Hi NoisyCoil,

Quoting NoisyCoil (2024-10-23 18:28:02)

I dislike that approach.

SemVer explicitly do not support stability across major releases,
which implies that no stability is promised about a feature having same
API across major releases.

I find it bad to encourage SemVer-breakage by offering non-SemVer
virtual packages.

Individual packages are still free to not care about SemVer but then
need to fully admit that by depending on the core crate, without
features.

Kind regards,

 - Jonas

Are you talking about the availability/unavailability of certain features? If yes, all of debcargo-conf's packages involved in the 2->3 transition depend on the default feature, so it would be enough to Provide librust-lazy-regex+default-dev. If not I'd appreciate it if you could elaborate on

It may be my inexperience talking, but it is unclear to me how features are involved here. How does "depending on the core crate, without features" equate to fully admitting that a package does not care about SemVer (if not for the availability/unavailability of features)? I don't understand what features add to this, logically.

Quoting noisycoil@tutanota.com (2024-10-23 20:28:04)

b) "lazy-regex v2 feature 'default'" represent a subset of a)

c) "lazy-regex v3 represents a *different* API.

d) "lazy-regex v3 feature 'default'" represents a subset of b)

Since a) and c) are different, b) and d) are also different: They are
subsets of different APIs.

It is normal for a Debian package to provide and depend on API or ABI.

It is technically possible to offer or depend on some open-ended ranges
of APIs/ABIs, e.g. "the subset called 'default' of any API from v2 to
eternity".

I am arguing that if the Rust team wants to bind to "whatever API
lazy-regex throws at it for any arbitrary major version of the crate",
then I will not take part of that nonsense, but also I don't see that I
am stopping you from such practice: Simply declare an equally nonsense
dependency *without* including feature - e.g. like this:

Depends: librust-lazy-regex-dev (>= 2)

Hope that helps,

 - Jonas

Thanks for the clarification Jonas. I still struggle to see the logic in it (at least as it would apply to the default feature, I could make sense out of it for other features), but there's no point in arguing. As a Debian developer you have, of course, absolute freedom over how you decide to manage your own packages.

Given that


To the Rust Team: please note that because of the packaging choice of not providing unversioned feature packages (not even for the default feature), with the current tooling, depending on lazy-regex as 'lazy-regex = ">=2"' or similar in Cargo.toml -- that is, only using the major version and with the intention of also picking up higher major versions -- is utterly useless within debcargo-conf. The transition will have to proceed by touching all 13 packages in debcargo-conf that depend on librust-lazy-regex-dev [2], instead of the two that currently have a versioned dependency.



[1] https://rust-team.pages.debian.net/book/policy.html#provides-field
[2] E.g. using 'lazy-regex = "=3"' in Cargo.toml and uploading to experimental instead of only triggering binNMUs when appropriate.