Bug#1030957: release.debian.org: please have rust-rustls ignore CI tests for s390x and ppc64el
Quoting Sebastian Ramacher (2023-02-10 10:30:53)
> Control: tags -1 moreinfo
> Control: severity -1 normal
>
> On 2023-02-09 23:59:25 +0100, Jonas Smedegaard wrote:
> > Package: release.debian.org
> > Severity: important
> >
> > ckage src:rust-rustls is not migrating to testing because tests fail for
> > s390x and ppc64el. On both arches the failure is that the test
> > environment thinks it needs to install an arch-specific
> > librust-rustls-dev to satisfy a virtual dependency pointing back to
> > itself, which is (since recently) an arch-all package.
> >
> > I can only interpret that as the test environment on thos arches being
> > broken. Please don't punish the package for that :-(
> >
> > There seems to be same problem for rust-oxhttp, and rust-hyper-rustls.
> > Do you want a separate bugreport for each, or is it fine just mentioning
> > it here?
>
> What's the added benefit of the conversion to Architecture: all
> packages? Currently there does not seem to be a concensus to do this
> switch for rust packages and doing them shortly before the soft freeze
> apparently just generates work for the RT.
Reduced size in the archive: Avoids multiple identical copies of library
source code
Reduced complexity of APT: Avoids replicated packaging metadata
Avoids certain types of impossible-to-satisfy scenarios:
https://github.com/sagebind/threadfin/issues/3 is an example of a
complexity which due to differences in how crates.io and APT handles
variety in architecture support caused a dependency of
src:rust-threadfin to be impossible to migrate to testing because a
test-dependency was unavailable on a lesser-used architecture and could
not (easily) be skipped for single architectures. That concrete example
was luckily solved now before the freeze, but would have been quite
problematic to handle afte the freeze, and was the trigger for my
decisison to switch all of the Rust libaries I maintain to use the
format which is generally better understood in Debian context: arch-all
code should be packaged as arch-all packages.
Yes, I am aware that the Rust team packages arch-all code as arch-any
packages, but I am unaware that their reasoning is well documented
anywhere. The only reason I was aware of when I did the switch was
that Debian has a convenient processing of binNMUs but annoyingly
require source-only releases for rebuilding arch-all packages.
I certainly had no intention of causing additional burden for the
release team, and only learned about the hickups in infrastructure now
experienced when I did the switch. On the contrary, as explained above,
one of my reasons for doing the switch was to _reduce_ the risk of
release team headaches _after_ the freeze.
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
* Sponsorship: https://ko-fi.com/drjones
[x] quote me freely [ ] ask before reusing [ ] keep private
Reply to: