I finally decided to turn target 'build' into an alias of target 'build-arch' for all architectures. This is already done in some other packages (e.g. orsa) and cdbs provides explicit support for it. I know there is a bit of controversy on this but Policy is not strictly against it.
On Sat, 2008-08-16 at 22:46 -0300, Wouter Verhelst wrote: > On Fri, Aug 15, 2008 at 10:51:08PM +0200, FRANCISCO MOYA FERNANDEZ wrote: > > I already know that people do also build their own packages, thanks. You do > > not need to "rewire" the debian/rules in order to build zeroc-ice > > binary-arch > > packages but AFAIK in your PowerPC you cannot currently build zeroc-ice > > binary-all packages, no matter what I do. > > In that case, it's best to let the build actually *fail* on > non-i386 architectures, rather than allowing it to silently > succeed, perhaps by the non-installability of i386-specific > build-dependencies. Allowing a package builder to build a source > package in such a way that the _all.deb packages aren't built > without an error *will* cause confusion. Trust me. I never told you so. Package zeroc-ice will not succeed if you try to build a package in an unsupported architecture. OTOH target build will succeed on non-i386 architectures (now on all architectures) if build-arch succeeds. > > You do not need to issue an NMU if you find some binary-all packages that > > could be built in architectures other than i386. Report the bug and I will > > add them in the next release. > > There are many reasons why people may need to build your package. > You may be on holiday, and unable to upload a package in time for > the release. The security team may have to prepare a fix. Someone > may want to add a patch to their version of your package in their > derivation of Debian. A user may want to build a version locally > with a different compiler. So what? You can always build binary-arch. And as many packages of binary-indep as supported in your platform. > I'm sure there are more examples. > > Making that hard does not fit my description of "good packaging", > honestly. You are talking of making build fail on all non-i386 architectures and and now you tell me I'm making compilation by the user hard. Nice contradiction. > > The kludge will add another exception. Note that this is not a > > guarantee to be able to build binary-all but perhaps you could > > build binary/libzeroc-ice-java (?) > > > > The zeroc-ice build dependencies are right to the best of my knowledge, but > > dpkg-buildpackage -B do not currently check them all. Target build must > > satisfy Build-Depends-Indep (cf. Debian Policy 7.7) but dpkg-buildpackage > > fail to enforce that for binary-arch builds. > > I'm not sure I understand what you're trying to say here. Policy 7.7 states that target 'build' *must* satisfy Build-Depends *and* Build-Depends-Indep. Autobuilders enforce just Build-Depends but then use target 'build'. This has been discussed long ago, but AFAIK there is no consensus yet. > > This is a feature rather than a bug in my opinion. This makes it possible to > > use target build while the transition path to build-arch is defined. > > For clarity: "the transition to build-arch" is not actually in the > process of being defined, at all. This *is* a bug, IMAO. There is no need for a formal "process" to define this. There are lots of previous discussions on this, lots of patches to dpkg-buildpackage and friends, and lots of proposals ranging from new control fields to trial and error approaches. Eventually we will find the right one. > > Simply stated, zeroc-ice is a package with lots of dependencies. I'll do my > > best to get most of it working in as much architectures as possible. But I > > won't remove features in some architectures just to homogeneize the > > behaviour > > of debian/rules. Therefore I'm eager to receive suggestions on how to make > > it *better* supported on any architecture. But I won't accept "DO NOT DO > > THAT" statements unless properly supported on the Debian Policy. > > Debian Policy only knows as much as what we put in it. Therefore it > isn't almighty, and it *certainly* isn't a stick to beat people with, as > you're trying to do here. The fact that some insanity isn't in > policy doesn't mean you should suddenly start doing it in your > package. It was not my intention to use Policy as a stick but as the only authoritative argument I was willing to accept for destructive "DO NOT DO THAT" statements without further argumentation. Suggestions leading to a better user experience with my packages are welcome. Suggestions that reduce the feature set are not. But even in the latter case I'm willing to accept them if my approach is against Debian Policy. > Changing the behaviour o your debian/rules file based on the > architecture you're trying to build on, is a *very* bad idea, > policy or no policy. If you really, *really* must make sure that > build-indep isn't ran everywhere, then read Policy 4.9, `build', > paragraph 2: [...] > I'm sure you understand what I mean here. Not really. This paragraph applies when the build target does not make much sense. But zeroc-ice builds a single tree and building the whole package does really make sense. In any case I think the next release will be acceptable to you, as long as it does more or less the same as package orsa. Regards, Paco -- Francisco Moya Fernandez Computer Architecture and Networks Group Assistant Professor [EMAIL PROTECTED] School of Computer Science Fax:(+34 926) 29 53 54 University of Castilla-La Mancha Tel:(+34 926) 29 54 83 http://www.inf-cr.uclm.es/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
