[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: allow missing description fields and empty long descriptions for Rust/etc packages?



On Wed, Sep 20, 2023 at 10:10:58AM +0800, Paul Wise wrote:
> Hi all,
> 
> I have noticed that almost all Rust packages in Debian have boilerplate
> long descriptions that aren't very useful to Debian users. The only
> useful info is the crate name, but that is also in the package name.
> 
> As far as I know they inherit this property from the upstream Rust
> crates, which only have a synopsis or even no description at all.

the structured metadata of crates only has a short description[0], which
is often also not very meaningful. our tooling adds additional
boilerplate text that is automatically added (for example, which cargo
features or binaries a given package enables/contains), which is often
rather redundant (since the features for example are already contained
in the package name and/or provided virtual package names).

> Having the Rust team and other folks add non-upstream descriptions for
> crates seems like not very useful work, since the Rust packages are
> basically only used as build-deps and therefore have no human users.

> So I would like to suggest Debian relax our requirements around binary
> package descriptions, especially for Rust binary packages.
> 
> Does anyone object to this change?

it seems like the consensus was not to go into this direction, but
rather to try and add more meaningful descriptions.

we could try harder in debcargo to extract from other sources
(with less structure), such as the first paragraph of a readme or of the
"main" documentation[1]. we have tooling in place that allows us to
track overrides of auto-generated files (e.g., d/control for rust crates
is usually completely autogenerated from upstream sources and a
declarative packaging config file, but if it is overridden, we check in
the auto-generated version so we notice any changes we might need to
fold into the override file), which could also be used to track changes
to the upstream "long descriptions" so that there is no unwanted
deviation over time.

as a last resort, we could also make explictly setting and checking in
an override for the generated (base) long description mandatory, if
desired.

0: https://doc.rust-lang.org/cargo/reference/manifest.html#the-description-field
1: https://doc.rust-lang.org/rustdoc/how-to-write-documentation.html#getting-started


Reply to: