Javier Serrano Polo skrev:
I'd like to bring your attention to bug #464796. It allows to drop the amd64 hack, using alternative build dependencies. Robert may be interested in building from this. I have a simplified list of dependency changes (0.9.53) if you need to start from somewhere.
OK, but I updated the build dependencies in 0.9.54 (added unixodbc-dev, removed libungif4-dev).
In the meantime, I'll package an amd64 wine, unless you want to do it. Ove, if you're uploading 0.9.55 before next week, please tell me and I'll wait for it.
Well, I was planning to upload a 0.9.55 one of these days, and I wanted to include amd64 patches if I had any (so far I've got that build-dependency on lib32z1-dev). Of course, I cannot actually build an amd64 package without the build daemon's help, but at least I can make it easier for the users to build the package on their own...
If I understand you right, you're suggesting building Wine amd64 packages using build-dependencies from an unofficial repository, and uploading that to the official Debian repository, binNMU-style. I'm not sure that's really a solution. (Perhaps it would technically be a violation of policy on some level, too, since Wine is in main, not contrib.) Sure, Wine's current amd64 hack is neither prettier nor really more secure than that, but at least it is possible to build the amd64 package without changing /etc/apt/sources.list, and thus, the amd64 build daemon would be able to build it (if ia32-libs wasn't broken). With your unofficial repository, I don't see any way I could have the amd64 package updated every time I update the i386 package.
Like now, if you NMU-ed 0.9.54, and I later got around to uploading the 0.9.55 with these ia32-*-dev build deps you used, then amd64 users would *still* be out of luck.
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
