On Tue, 20 Nov 2007, Aurelien Jarno wrote: > Even if it is not important for you that doesn't give you the right to > ignore the problem as you did until now.
We've had only one unconclusive IRC discussion, that's not really ignoring the problem. And I still believe, you're over exagerating the problem unless there are good reasons why exported API differ on unofficial architectures more than on official architectures (this could be the case for kfreebsd-*, I don't know). > 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. And we'll make sure to find a statisfying solution once you give me all the relevant infos to really understand how far reaching the problem is. > > 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. Did you read what I wrote? I said "it will not fail" if the package provides only debian/*.symbols.<arch>. > And note that I am speaking of real examples. Just try on libusb for > example. On which architecture did you try? And how? Where do I have an account on an armel machine or a kfreebsd one? Note that this is a case where the API is supposed to be stable across architectures... can you show me what the differences are and why they are legitimate? Please show me the build-failure. > > 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. This is surely a feature that could be added to sbuild. I asked neuro on IRC, I'm waiting his answer. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
