Re: optional package in Build-Depends (how?)
Hi Russ, On Monday 27 February 2012 17:59:28 Russ Allbery wrote: Another package I was recently testing on GNU Hurd where some tests were failing (even though the package is working). A bug in the test suite? It's worth being careful about assuming that the package is working when the tests are failing. :) Sorry, sorry, never mind. :) Actually I couldn't find peace with it so I checked again I realised that tests actually are not failing on Hurd. Fortunately I was wrong. :) All good, no need to ignore. So again I had to ignore post-build test(s) failure. I don't think that makes sense to do for Hurd, actually. The package needs to be ported to it; I would let the build fail until that's happened. That may mean just porting the test suite or the test suite may be uncovering a real issue. That's generally what I do with any non-release architecture until I have time to do the (low priority, usually) porting work. You don't want to accidentally hide failures that need porting effort by making the build succeed artificially. Fully agreed. Testing still useful to me when I read build logs, but I'm very reluctant to introduce a potential failure point with dependency more strict than necessary. Making the *dependency* strict isn't going to add a failure point. It's not like valgrind is going to disappear on i386 and amd64. True, good point to keep in mind when considering. If the build failures are mostly due to bugs in the test suite, I agree with you. That's the criteria on which I'd make the decision. If the tests are finding bugs, then the failures are valuable and shouldn't be suppressed. That's common sense, I can only agree. And it appears to me that if tests failure is already pretty much ignored is would be acceptable to make tests optional with weak build dependency. However, Debian quite intentionally does not have such a thing as a weak build dependency, nor do I think such a thing is appropriate here. Rather, I think you should make a decision: either depend on the tools required to run the tests and ignore the test failures (if you think they're bugs in the test suite and not the package) if the output is valuable, or don't depend on the tools and skip the tests. Thank you, I think this is a good advice. I'll keep it in mind. All the best, Dmitry. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201202272049.33489.only...@member.fsf.org
Re: optional package in Build-Depends (how?)
In case someone is tempted to try Build-Depends like check | dpkg, it doesn't work at all in pbuilder which is smart enough to notice that dpkg is already installed so it never pulls 'check'. (Anyway particular example with check is silly because check is available on all architectures) Apart from that such approach will provoke a nasty lintian error. So this idea is not worth the effort. As Russ Albury noticed earlier, Debian quite intentionally does not have such a thing as a weak build dependency, nor do I think such a thing is appropriate here. Regards, Dmitry. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201202280245.33508.only...@member.fsf.org
Re: optional package in Build-Depends (how?)
On Tue, 28 Feb 2012 02:45:33 +1100, Dmitry Smirnov wrote: In case someone is tempted to try Build-Depends like check | dpkg, it doesn't work at all in pbuilder which is smart enough to notice that dpkg is already installed so it never pulls 'check'. And it also doesn't work -- the other way round -- on the buildds where sbuild is configured to only look at the first alternative. Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Bob Dylan: Standing In The Doorway signature.asc Description: Digital signature
optional package in Build-Depends (how?)
Dear mentors, I have an interesting problem on my hands: The package I need to build have optional build dependency (libgpm-dev) which is not available on all platforms. If I just put it to Build-Depends, package will FTBFS on some platforms. So idea is to specify an optional (soft) build-dependency like Build-Depends: libgpm-dev | TRUE where 'TRUE' would stand for essential package like 'dpkg'. However I suspect there must be a better way to do that, a practical equivalent to hypothetical 'Build-Recommends'. What would be the best practice for such case? Any suggestions? Thank you. All the best, Dmitry. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201202271251.20803.only...@member.fsf.org
Re: optional package in Build-Depends (how?)
See section 7.1 of debian-policy for examples on how to do that (you probably want linux-any for the arch): http://www.debian.org/doc/debian-policy/ch-relationships.html -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6GGCM8N3g1iWMhYzcdPWBu7GWmzK9e7BQ7w=rdzq6k...@mail.gmail.com
Re: optional package in Build-Depends (how?)
Hi Paul, Thanks for quick reply. On Monday 27 February 2012 13:00:32 Paul Wise wrote: See section 7.1 of debian-policy for examples on how to do that (you probably want linux-any for the arch): http://www.debian.org/doc/debian-policy/ch-relationships.html Indeed it probably could be written as Build-Depends: libgpm-dev [linux-any] But the obvious drawback would be the requirement to know all architectures where this package is available. In this case Build-Depends configuration will be ineffective against changes. Maintainer will have to track if the package was ported to new architecture and maintaining such relationships may potentially turn into expanded list of architectures. Perhaps it will work beautifully for dependencies which will never be ported. But let's discuss more general case: what if optional dependency is not ported to target architecture yet, or if if is not available in backports? There are might be situations where defining optional build dependencies without architecture wildcard may be more error-proof and easier to maintain. Another case I'm thinking of is when upstream is using unit-testing framework like 'valgrind'. I like to have post-build tests enabled. But this functionality requires an optional dependency. I don't want to risk my package to FTBFS because I put dependency only needed for unit tests to Build-Depends and it is not available on all our platforms. In such case using architecture wildcard is just inappropriate because availability of such package (may) have nothing to do with architecture. Specifically regarding 'libgpm-dev', I've made a list of architectures where it is available (below). At the moment I have no idea what 's390x' is (linux or not) so I have doubts regarding architecture wildcars to use. (OK, I admit I've checked with 'type-handling any linux-gnu' command but I'm still confused how to use architecture wildcards properly in this case) All of this makes me think about the approach to use essential alternative to make sure build will never fail because of my lack of understanding which platform will have the required package. What do you think? libgpm-dev avr32 N hppaN hurd-i386 N kfreebsd-amd64 N kfreebsd-i386 N s390x N alpha Y amd64 Y armel Y i386Y ia64Y m68kY mipsY mipsel Y powerpc Y armhf Y powerpcspe Y s390Y sh4 Y sparc Y sparc64 Y Regards, Dmitry. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201202271342.28308.only...@member.fsf.org
Re: optional package in Build-Depends (how?)
On Mon, Feb 27, 2012 at 01:42:28PM +1100, Dmitry Smirnov wrote: Indeed it probably could be written as Build-Depends: libgpm-dev [linux-any] But the obvious drawback would be the requirement to know all architectures where this package is available. In this case Build-Depends configuration will be ineffective against changes. That's the problem I have with mudlet. libluajit-5.1-dev [amd64 armel i386 kfreebsd-i386], liblua5.1-0-dev [!amd64 !armel !i386 !kfreebsd-i386], It's not pretty and basically means if other arches come along and support libluajit I have to manually fix it. I don't think I could use or | because it didn't work on some build systems. A or nothing would be handy but I always get worried that you will miss linking because of a transistional bump then the program behaviour changes. Imagine if on the armel libluajit is not available temporarily. I think its better to fail to build than to issue out a package without that linking. Specifically to your testing, valgrind testing should probably be opportunistic, so test if valgrind is available and don't otherwise. I think dejagnu does it that way. - Craig -- Craig Small VK2XLZ http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120227030921.gb1...@enc.com.au
Re: optional package in Build-Depends (how?)
Hi Craig, Thak you for sharing your experience. On Monday 27 February 2012 14:09:21 Craig Small wrote: That's the problem I have with mudlet. libluajit-5.1-dev [amd64 armel i386 kfreebsd-i386], liblua5.1-0-dev [!amd64 !armel !i386 !kfreebsd-i386], Very interesting and useful. This is exactly what I'm afraid of. How can fellow maintainer track the changes in all architectures effectively? I imagine the maintenance pain for such configuration and it is probably breaks once in a while... It's not pretty and basically means if other arches come along and support libluajit I have to manually fix it. I don't think I could use or | because it didn't work on some build systems. I see... A or nothing would be handy but I always get worried that you will miss linking because of a transistional bump then the program behaviour changes. Imagine if on the armel libluajit is not available temporarily. I think its better to fail to build than to issue out a package without that linking. This is a very valid point, thank you. You're right, if libgpm-dev is not available on i386 or amd64 for whatever reason, build should fail rather than ignore the problem. Which makes this dependency package optional only on some architectures so I probably need to use something like libgpm-dev [!kfreebsd-i386 !kfreebsd-amd64 !hurd-i386], or libgpm-dev [linux-any], It's not too bad after all. Specifically to your testing, valgrind testing should probably be opportunistic, so test if valgrind is available and don't otherwise. I think dejagnu does it that way. OK, so for really optional packages like 'check' or 'bison' it may be appropriate to use something like check | dpkg if we're not linking against it. I understand it much better now. Thank you. Cheers, Dmitry -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201202271518.25990.only...@member.fsf.org
Re: optional package in Build-Depends (how?)
Dmitry Smirnov only...@member.fsf.org writes: On Monday 27 February 2012 14:09:21 Craig Small wrote: Specifically to your testing, valgrind testing should probably be opportunistic, so test if valgrind is available and don't otherwise. I think dejagnu does it that way. OK, so for really optional packages like 'check' or 'bison' it may be appropriate to use something like check | dpkg if we're not linking against it. I would only consider using a hack like this if the package really isn't available everywhere. For something like bison, just build-depend on bison and be done with it. As much as possible, you should try to ensure that the package builds exactly the same way everywhere, using the same tools, and only back off from that if some tool really isn't available at all on some target architecture. Even with valgrind, personally I'd just list a specific set of architectures on which valgrind is required, even if you also opportunistically test for its existence. There's no reason to allow *not* running valgrind tests on i386 and amd64. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877gz86gsc@windlord.stanford.edu
Re: optional package in Build-Depends (how?)
Hi Russ, On Monday 27 February 2012 15:28:51 Russ Allbery wrote: Even with valgrind, personally I'd just list a specific set of architectures on which valgrind is required, even if you also opportunistically test for its existence. There's no reason to allow *not* running valgrind tests on i386 and amd64. It makes perfect sense for complete (working) test suits. I had an experience with valgrind only recently when upstream introduced yet-to-be completed tests which are failing everywhere so far. I'm already ignoring tests failure using override override_dh_auto_test: -dh_auto_test In which case it makes perfect sense not to take the risk of FTBFS on some architectures for the sake of testing which is not even useful yet. Another package I was recently testing on GNU Hurd where some tests were failing (even though the package is working). So again I had to ignore post-build test(s) failure. Testing still useful to me when I read build logs, but I'm very reluctant to introduce a potential failure point with dependency more strict than necessary. While I'm with you and I fully share the desire not to allow skipping tests on i386 or amd64, I think risk of FTBFS outweighs it. You see, When I build the package on my amd64 host I will likely to notice if something goes wrong but my concern is more about architectures I have no access to. I'm not yet in habit of reading all build logs from all architectures upon package upload when the build was successful. And it appears to me that if tests failure is already pretty much ignored is would be acceptable to make tests optional with weak build dependency. Regards, Dmitry. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201202271628.51099.only...@member.fsf.org
Re: optional package in Build-Depends (how?)
Dmitry Smirnov only...@member.fsf.org writes: It makes perfect sense for complete (working) test suits. I had an experience with valgrind only recently when upstream introduced yet-to-be completed tests which are failing everywhere so far. I'm already ignoring tests failure using override override_dh_auto_test: -dh_auto_test In which case it makes perfect sense not to take the risk of FTBFS on some architectures for the sake of testing which is not even useful yet. Oh, okay, yes, if you're already ignoring errors from the test, then I'd only build-depend on valgrind where you want to see the results in the build logs for further work. Another package I was recently testing on GNU Hurd where some tests were failing (even though the package is working). A bug in the test suite? It's worth being careful about assuming that the package is working when the tests are failing. :) So again I had to ignore post-build test(s) failure. I don't think that makes sense to do for Hurd, actually. The package needs to be ported to it; I would let the build fail until that's happened. That may mean just porting the test suite or the test suite may be uncovering a real issue. That's generally what I do with any non-release architecture until I have time to do the (low priority, usually) porting work. You don't want to accidentally hide failures that need porting effort by making the build succeed artificially. Testing still useful to me when I read build logs, but I'm very reluctant to introduce a potential failure point with dependency more strict than necessary. Making the *dependency* strict isn't going to add a failure point. It's not like valgrind is going to disappear on i386 and amd64. While I'm with you and I fully share the desire not to allow skipping tests on i386 or amd64, I think risk of FTBFS outweighs it. You see, When I build the package on my amd64 host I will likely to notice if something goes wrong but my concern is more about architectures I have no access to. I'm not yet in habit of reading all build logs from all architectures upon package upload when the build was successful. You will generally get mail if the build fails. If the build failures are mostly due to bugs in the test suite, I agree with you. That's the criteria on which I'd make the decision. If the tests are finding bugs, then the failures are valuable and shouldn't be suppressed. And it appears to me that if tests failure is already pretty much ignored is would be acceptable to make tests optional with weak build dependency. However, Debian quite intentionally does not have such a thing as a weak build dependency, nor do I think such a thing is appropriate here. Rather, I think you should make a decision: either depend on the tools required to run the tests and ignore the test failures (if you think they're bugs in the test suite and not the package) if the output is valuable, or don't depend on the tools and skip the tests. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871upgsqwf@windlord.stanford.edu
