Raphael Hertzog a écrit : > severity 452022 wishlist > thanks > > On Mon, 19 Nov 2007, Aurelien Jarno wrote: >> Package: dpkg-dev >> Version: 1.14.8 >> Severity: serious > > Huh ?! I know it's important for you, but that doesn't make it RC.
Even if it is not important for you that doesn't give you the right to ignore the problem as you did until now. I guess it is also very important for the release team, because armel is supposed to be shipped with lenny in order to drop arm for lenny + 1. This architecture has to be kept in good shape. >> problem: it potentially breaks all unofficial architectures, as the >> symbols for those architectures are not available on mole and may >> vary a bit. > > This is not a justification. > >> This causes packages to fails to build in case of differences in the >> list of symbols, and will progressively break all unofficial >> architectures, even those that we want to *integrate as an official* >> architecture sooner or later. > > You're too pessimistic IMO. If the package has > debian/<package>.symbols.<arch> files then it will not fail because it > won't find a symbols file for the given architecture and will thus > generate a brand new one (and the comparison will only find new symbols > and it will not fail). > As already explained, this is the case. Mole doesn't provide symbols for unofficial architectures (which I can understand), so packages will never have the symbols file for unofficial architectures. And note that I am speaking of real examples. Just try on libusb for example. > It will only fail if the package provides a debian/package.symbols file > (i.e. common to all architectures) and if symbols listed in that file > disappear on non-official architectures. > >> As already suggested, please ignore new or missing symbols on >> unofficial architectures and generate a new symbols file in that case >> (the current list of official architectures is: alpha amd64 arm hppa >> hurd-i386 i386 ia64 m68k mips mipsel powerpc s390 sparc). > > I won't harcode such a behaviour in dpkg. However what is doable is have > an environment variable that will override the "check level" that that the > package is using. Then you just have to make sure that the buildd of the > unofficial arches define that environment variable. > > Does that seem reasonable? Unfortunately I don't really like this idea because sbuild doesn't keep environment variables, and I don't really want to patch sbuild every time I want to update it instead of using the .deb package directly from debian-admin. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `- people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
