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
