Re: virtual packages for Ada libraries
On Sun, Jul 16, 2023 at 7:50 AM Jonas Smedegaard wrote: > I now recall: The Rust library packages wreaking havoc by prematurely > entering testing is (at least partly) due to the Rust team choosing to > flag all(!) autopkgtests as flaky, so not really a concern for other > teams (read: just don't take inspiration from that particular pattern). They aren't all flaky but skip-not-installable is used frequently. Thank you, Jeremy Bícha
Re: virtual packages for Ada libraries
Quoting Jonas Smedegaard (2023-07-15 10:05:24) > Quoting Nicolas Boulenguez (2023-07-12 15:55:09) > > The Ada maintainers are considering a new naming scheme for -dev packages, > > where > > libada-foo-dev Provides: libada-foo-dev-HASH. > > source packages Build-Depend: libada-foo-dev > > binary -dev packages Depend: libada-foo-dev-HASH > > The intent is similar to the one of shared object versions, but the > > name changes often (for example, with the architecture) and is > > computed, so virtual packages seem more appropriate. > > > > Policy 3.6 does not disapprove: > > ... should not use virtual package names (except privately, > > amongst a cooperating group of packages) unless they have been > > agreed upon and appear in the list of virtual package names. > > However politeness recommends to ask for objections before polluting > > the package namespace. > > > > Haskell and Ocaml apparently use a similar scheme. > > I have no objections to this - it sounds like a good approach. > > Just want to point out that experience from Rust packaging indicates > that general Debian tooling does a weaker job at dependency resolving > for vritual packages, which (for Rust libraries) causes breakages of > reverse dependencies, and may even (not quite sure) lead to breakage of > testing due to libraries with unsatisfied (dependencies) migrating. I now recall: The Rust library packages wreaking havoc by prematurely entering testing is (at least partly) due to the Rust team choosing to flag all(!) autopkgtests as flaky, so not really a concern for other teams (read: just don't take inspiration from that particular pattern). - 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 signature.asc Description: signature
Re: virtual packages for Ada libraries
Hi Le sam. 15 juil. 2023, 10:05, Jonas Smedegaard a écrit : > Quoting Nicolas Boulenguez (2023-07-12 15:55:09) > > The Ada maintainers are considering a new naming scheme for -dev > packages, > > where > > libada-foo-dev Provides: libada-foo-dev-HASH. > > source packages Build-Depend: libada-foo-dev > > binary -dev packages Depend: libada-foo-dev-HASH > > The intent is similar to the one of shared object versions, but the > > name changes often (for example, with the architecture) and is > > computed, so virtual packages seem more appropriate. > > > > Policy 3.6 does not disapprove: > > ... should not use virtual package names (except privately, > > amongst a cooperating group of packages) unless they have been > > agreed upon and appear in the list of virtual package names. > > However politeness recommends to ask for objections before polluting > > the package namespace. > > > > Haskell and Ocaml apparently use a similar scheme. > > I have no objections to this - it sounds like a good approach. > > Just want to point out that experience from Rust packaging indicates > that general Debian tooling does a weaker job at dependency resolving > for vritual packages, which (for Rust libraries) causes breakages of > reverse dependencies, and may even (not quite sure) lead to breakage of > testing due to libraries with unsatisfied (dependencies) migrating. Two remarks: - Since OCaml used this approach, I also implemented something similar for Coq packages ; - Indeed this is quite fragile; I have two scripts for Coq packages [1]: one to tell me about the deps (I give it which package I have to upgrade and it gives the list of affected packages by pass) and the other to generate the migration script (I give it the list of new packages and their new version and it generates what I have to tell FTP masters), but it's still pretty painful. Perhaps if there are several such instances of such package dependency networks we should try to find a common and efficient solution Debian-wide ? Cheers, J.Puydt [1] https://tracker.debian.org/pkg/dh-coq
Re: virtual packages for Ada libraries
Quoting Nicolas Boulenguez (2023-07-12 15:55:09) > The Ada maintainers are considering a new naming scheme for -dev packages, > where > libada-foo-dev Provides: libada-foo-dev-HASH. > source packages Build-Depend: libada-foo-dev > binary -dev packages Depend: libada-foo-dev-HASH > The intent is similar to the one of shared object versions, but the > name changes often (for example, with the architecture) and is > computed, so virtual packages seem more appropriate. > > Policy 3.6 does not disapprove: > ... should not use virtual package names (except privately, > amongst a cooperating group of packages) unless they have been > agreed upon and appear in the list of virtual package names. > However politeness recommends to ask for objections before polluting > the package namespace. > > Haskell and Ocaml apparently use a similar scheme. I have no objections to this - it sounds like a good approach. Just want to point out that experience from Rust packaging indicates that general Debian tooling does a weaker job at dependency resolving for vritual packages, which (for Rust libraries) causes breakages of reverse dependencies, and may even (not quite sure) lead to breakage of testing due to libraries with unsatisfied (dependencies) migrating. - 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 signature.asc Description: signature
virtual packages for Ada libraries
Hello. The Ada maintainers are considering a new naming scheme for -dev packages, where libada-foo-dev Provides: libada-foo-dev-HASH. source packages Build-Depend: libada-foo-dev binary -dev packages Depend: libada-foo-dev-HASH The intent is similar to the one of shared object versions, but the name changes often (for example, with the architecture) and is computed, so virtual packages seem more appropriate. Policy 3.6 does not disapprove: ... should not use virtual package names (except privately, amongst a cooperating group of packages) unless they have been agreed upon and appear in the list of virtual package names. However politeness recommends to ask for objections before polluting the package namespace. Haskell and Ocaml apparently use a similar scheme.
