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
Francisco.Moya@uclm.es 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Some autobuilders wait for build-indep dependencies
