Re: Multi-Arch: allowed
On Sat, Nov 19, 2016 at 05:53:04PM +0100, Julien Cristau wrote: > On Tue, Nov 1, 2016 at 18:11:27 +0100, Thibaut Paumard wrote: > > > The -dbg package is Multi-Arch same. It Depends on the packages for > > which it provides debugging symbols, some of which are Multi-Arch: > > allowed. > > That Depends seems wrong, there's no reason a -dbg package needs a > dependency on anything, AFAICT. A -dbg package only works with the exact version of the package it provides the debug symbols for. > Cheers, > Julien cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Multi-Arch: allowed
On Tue, Nov 1, 2016 at 18:11:27 +0100, Thibaut Paumard wrote: > The -dbg package is Multi-Arch same. It Depends on the packages for > which it provides debugging symbols, some of which are Multi-Arch: > allowed. That Depends seems wrong, there's no reason a -dbg package needs a dependency on anything, AFAICT. Cheers, Julien
Re: Multi-Arch: allowed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear David, Le 02/11/2016 à 01:05, David Kalnischkies a écrit : > I would add: > > * Check if gyoto-bin really needs to be M-A:allowed. Name, > Description and the list of filenames included in the package > suggest to me that the package can and should be M-A:foreign – or > in other words: Why is it allowed? Up to now, this is purely theoretical as no package outside of src:gyoto depends or build-depends on gyoto-bin. However, I am considering splitting some of the plug-ins into separate source packages, so I have some interest in doing it right. Some background: Gyoto is a framework for doing some type of scientific numerical computations (general relativistic ray-tracing, to be precise). The package is split as follows: - - gyoto: metapackage that depends on the rest; - - gyoto-dbg: the debugging symbols package that we'll drop at some point; - - libgyoto5: the main C++ library plus standard plug-ins, M-A: same; libgyoto5 Recommends gyoto-bin as it needs it for MPI computations (see below); - - libgyoto5-dev: obvious, M-A: same; - - yorick-gyoto, python-gyoto, python3-gyoto: interpreted interfaces for three interpreters. The Python flavours also include Gyoto plug-ins (for using Python from Gyoto). M-A: allowed on the premise that the interpreters are "allowed" themselves, and you can use the interface in an arch-independant manner; - - gyoto-bin contains two binaries: gyoto: command line tool to render XML sceneries into FITS images. If you build-depend on it just to do some ray-tracing with the standard plug-ins, then it really is foreign (to machine precision, the result does not depend on the architecture). If you build-depend on it to test a plug-in, then you need to be running the same architecture as the one of the plug-in. In general, you will need the same arch for all your plug-ins as for the interface. So M-A: foreign looks wrong to me, it is either "no" or "allowed". gyoto-mpi-worker.: This binary is spawned by MPI for parallel computations (possibly running on another computer), independent of whether the parallel computation is started from the gyoto command-line tool above or from on of the interpreted interfaces. There, I actually don't know whether the spawned processes need to be of the same architecture as the spawning process. When running on distinct hosts, I think not, but this case is orthogonal to the Multi-Arch issue. So I am not sure whether "foreign" would work either. > Rule of thumb: Don't make any package M-A:allowed as long as you > haven't got a bugreport telling you it would be nice from some > cross-folks (be it grader, builder, bootstrapper, …). Reason is > that M-A:same/foreign is instantly useable/ful, but M-A:allowed is > useless if nothing ends up depending on it with :any. "foreign" looks wrong to me in this case, we need to be able to build and test plug-ins. On the other hand, my understanding was that "allowed" was "mostly M-A:no unless otherwise specified", so surely it does not hurt? Kind regards and thanks for your explanations. Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJYGa+lAAoJEJOUU0jg3ChA/YEP/2LYwjIAxnZWkj/d1Ga552lO gvuGoYMpR5jeE24QaZKWuleVfP2K7/hazL2FKPoO0JR5KVxgDKT8SeocsH3kVbBl U9uPLbuZzkifHMHw9PTNL7EL2OMKKzJAus3pVOTPS+q5pMJ6u73YbIumBQW3xWiE 5uro3puR3fKeroQ+FS8eKY/P+El8avNhGvn6qbAT/+IG+4CgFka2TD9u7VOGHlsQ RYY3IwBFWYal4C87gDbJMMc0bF1TxWqKVDYorTl9ls+1Pcbm5O9J/N1prezuL7uj /IBzz8+cgH0BZhhk6uIEmiyLINLNLIWbwc1/ZxEbZa7gwcWA0HIuDsbaSiV3Va7K 7iUipNQlncGQLqB5R0gTKalwM+/XXLGDMaO4nG1iqVNZVUBGvlmsNmDsTNukyKmR 3AaoIVrgj/dEGVRXQjxH0sEgbrDzM8SDpZDvnWI73cp/Yb5AaazLQnyScs9PCT2y RAM67BnzZ23ysOyQ9AAjz+l7qn18ETmxOQ0zS78BqJKmDZZvD2Anlz7vZydosL2Y mX58rW0xQtYUXytlsLXvseNsEpEPuHgO+gr0cPtYKPoIcIdeV5w9eBYhvvTkJVUW LJ8FXwVtbcfHIcQl7/lj2mSAkHg5kt+QIPVbBUFTQBEl967XYnYxcxISvZJJA4sp eUMahgF0PKHVYcTU4PHY =h5Ja -END PGP SIGNATURE-
Re: Multi-Arch: allowed
On Tue, Nov 01, 2016 at 09:24:10PM +, Simon McVittie wrote: > On Tue, 01 Nov 2016 at 18:11:27 +0100, Thibaut Paumard wrote: > > The -dbg package is Multi-Arch same. It Depends on the packages for > > which it provides debugging symbols, some of which are Multi-Arch: > > allowed. Lintian complains when I don't specify an architecture for > > those packages: > > > > W: gyoto source: dependency-is-not-multi-archified gyoto-dbg depends > > on gyoto-bin (multi-arch: allowed) > > N: > > N:The package is Multi-Arch "same", but it depends on a package > > that is > > N:neither Multi-Arch "same" nor "foreign". > > It is not useful for gyoto-dbg to be Multi-Arch: same as long as it > Depends on gyoto-bin. > > Imagine you want to be able to debug gyoto i386 and amd64 libraries, > or some other pair of architectures, at the same time (which is the > reason why Multi-Arch: same debug symbols are useful). You install > libgyoto0:amd64 and libgyoto0:i386 (or whatever the SONAME is); fine. > Next you install gyoto-dbg:amd64, which pulls in gyoto-bin:amd64; still > fine so far. Finally, you try to install gyoto-dbg:i386, but it Depends > on gyoto-bin:i386, which is not co-installable with gyoto-bin:amd64, > so you can't. > > You can either: > > * stop generating gyoto-dbg, and get the automatic debug packages > (but they won't be made available in jessie-backports) > > * remove the Multi-Arch field from gyoto-dbg > > * weaken its Depends on gyoto-bin to a Recommends or something I would add: * Check if gyoto-bin really needs to be M-A:allowed. Name, Description and the list of filenames included in the package suggest to me that the package can and should be M-A:foreign – or in other words: Why is it allowed? * otherwise: Check if gyoto-bin can't be split up into a package which can be marked M-A:foreign and one which can be marked M-A:same. Rule of thumb: Don't make any package M-A:allowed as long as you haven't got a bugreport telling you it would be nice from some cross-folks (be it grader, builder, bootstrapper, …). Reason is that M-A:same/foreign is instantly useable/ful, but M-A:allowed is useless if nothing ends up depending on it with :any. Best regards David Kalnischkies signature.asc Description: PGP signature
Re: Multi-Arch: allowed
On Tue, 01 Nov 2016 at 18:11:27 +0100, Thibaut Paumard wrote: > The -dbg package is Multi-Arch same. It Depends on the packages for > which it provides debugging symbols, some of which are Multi-Arch: > allowed. Lintian complains when I don't specify an architecture for > those packages: > > W: gyoto source: dependency-is-not-multi-archified gyoto-dbg depends > on gyoto-bin (multi-arch: allowed) > N: > N:The package is Multi-Arch "same", but it depends on a package > that is > N:neither Multi-Arch "same" nor "foreign". It is not useful for gyoto-dbg to be Multi-Arch: same as long as it Depends on gyoto-bin. Imagine you want to be able to debug gyoto i386 and amd64 libraries, or some other pair of architectures, at the same time (which is the reason why Multi-Arch: same debug symbols are useful). You install libgyoto0:amd64 and libgyoto0:i386 (or whatever the SONAME is); fine. Next you install gyoto-dbg:amd64, which pulls in gyoto-bin:amd64; still fine so far. Finally, you try to install gyoto-dbg:i386, but it Depends on gyoto-bin:i386, which is not co-installable with gyoto-bin:amd64, so you can't. You can either: * stop generating gyoto-dbg, and get the automatic debug packages (but they won't be made available in jessie-backports) * remove the Multi-Arch field from gyoto-dbg * weaken its Depends on gyoto-bin to a Recommends or something Regards, S
Re: Multi-Arch: allowed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear David, Le 01/11/2016 à 15:57, David Kalnischkies a écrit : > On Tue, Nov 01, 2016 at 02:43:21PM +0100, Thibaut Paumard wrote: >> How do you actually use Multi-Arch: allowed? Should a dependent >> package then specify either :same or :foreign? >> Looks > > Neither is valid syntax. What you do with these is depending on a > package with the literal architecture "same" (or "foreign"). Thats > not going to work… > > >> I was able to find documentation about what allowed is supposed >> to do, but not on how to depend on such a package. >> https://wiki.debian.org/Multiarch/HOWTO > > The spec [0] linked from that page says how, but in summary: Thanks, I was not able to parse it correctly apparently. > If a package (lets say perl) is marked as Multi-Arch: allowed your > package foo can depend on perl:any and a perl package from any > (foreign) architecture will statisfy this dependency, while a > 'simple' perl would have just accepted a perl from the architecture > your package foo was built for (with arch:all mapped to > arch:native). > [...] > If it helps: Instead of "perl having Multi-Arch: allowed" envision > it to have a "perl provides perl:any" and you are depending on this > virtual package – which also explains why such a missing provides > causes perl:any to be unresolveable. That makes things clearer, thanks. > > That said, the usecase for 'allowed' is small – mostly > interpreters – and you are trying to use it on… a -dbg package? I > haven't looked closely, but that smells wrong… What are you trying > to express here? The -dbg package is Multi-Arch same. It Depends on the packages for which it provides debugging symbols, some of which are Multi-Arch: allowed. Lintian complains when I don't specify an architecture for those packages: W: gyoto source: dependency-is-not-multi-archified gyoto-dbg depends on gyoto-bin (multi-arch: allowed) N: N:The package is Multi-Arch "same", but it depends on a package that is N:neither Multi-Arch "same" nor "foreign". N: N:Refer to https://wiki.ubuntu.com/MultiarchSpec for details. N: N:Severity: normal, Certainty: possible N: N:Check: group-checks, Type: source N: By the way, by the same logic that interpreters should (or can?) be Multi-Arch: allowed, I expect that - extensions for those interpreters also should (or can?); - any tool that is able to process an input data file to produce a arch-independent output also should (or can?) be either "foreign" or "allowed". Is that correct? > (and have you heard that automatic debug packages are a thing > nowadays?) Yes. Last time I checked, it was not clear how to use them in backports though. > > > Best regards > > David Kalnischkies > > [0] https://wiki.ubuntu.com/MultiarchSpec [1] There are ways around > it. See the "If it helps" remark for a hint. > Kind regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJYGMy/AAoJEJOUU0jg3ChA+hwQAKh7C+MfqrTPAL8WPQeUVAQh ZT6N2R2ugOmUBwW2wGtLvA1V6A6Nr9QME7Yjs9DVppd8kV5mWmOT1hJMyu+Wn0Hi XNvDIKrH9R6vgdRRyIxZIeSFdedf8QUYmEPnP7hkE8oTazFcTe8LpZfB4Ju3Blbp u+er1S7qSBei9ZEpsYKP13HA9G1C33Y7rTmgCgqm9sxuk7GmPiF5CKGR2JHS7kAZ YVodtJOF7diiuKfP6XQdKNUCgjH7x9EHk8BZ9s4sNeOb+TpAPRlvhTdb4c30i32e vGBUtP8VLRHH8IfxxrldmJecb8StHg+uE1+nM9jBFYRJ/hPAq1z22SeY1COMwyyd JSBaCD24XBC+YGgOBfVTz8F7r6hkumuQoJhgcARhRCVkYPQ9hxYFnzgz1igcoSTt tJ8YKgObWdItjC8MF9a1fayPwS7krAwKdB+/h4aZqft8fXPgc+d16b+8izjRvRhP 1WHp2GnG9Y3Tstvibge7AH13J2u/NxykZc3OyN/SdW1FBdMAEUuVvRGYPG+4ddqL zycMWjmgy+5QS3ts246foT/4OSfG+30ooFct7ikLEnWajzd1u5IocB95/wUzgaKq 0+VNTj8tLUpWibIipNTxDHeVTRpGERzxJGqv20ztgtGSG6bX75gGrFncoev0ykox n7sbt9I4/AUJbqvrFoWM =UNTB -END PGP SIGNATURE-
Re: Multi-Arch: allowed
On Tue, Nov 01, 2016 at 02:43:21PM +0100, Thibaut Paumard wrote: > How do you actually use Multi-Arch: allowed? Should a dependent > package then specify either :same or :foreign? Looks Neither is valid syntax. What you do with these is depending on a package with the literal architecture "same" (or "foreign"). Thats not going to work… > I was able to find documentation about what allowed is supposed to do, > but not on how to depend on such a package. > https://wiki.debian.org/Multiarch/HOWTO The spec [0] linked from that page says how, but in summary: If a package (lets say perl) is marked as Multi-Arch: allowed your package foo can depend on perl:any and a perl package from any (foreign) architecture will statisfy this dependency, while a 'simple' perl would have just accepted a perl from the architecture your package foo was built for (with arch:all mapped to arch:native). DO NOT use ":any" on a package which is NOT marked as Multi-Arch: allowed [1]. This isn't satisfiable by ANYTHING, not even your native package. If it helps: Instead of "perl having Multi-Arch: allowed" envision it to have a "perl provides perl:any" and you are depending on this virtual package – which also explains why such a missing provides causes perl:any to be unresolveable. That said, the usecase for 'allowed' is small – mostly interpreters – and you are trying to use it on… a -dbg package? I haven't looked closely, but that smells wrong… What are you trying to express here? (and have you heard that automatic debug packages are a thing nowadays?) Best regards David Kalnischkies [0] https://wiki.ubuntu.com/MultiarchSpec [1] There are ways around it. See the "If it helps" remark for a hint. signature.asc Description: PGP signature
