[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]



On Mon, 3 Nov 2003, Andreas Metzler wrote:

> On Mon, Nov 03, 2003 at 07:49:05PM +0100, Santiago Vila wrote:
> > [...] I would like to see the real benefits from
> > changing the format of debian/rules.
>
> Did you miss the original subject of the thread? The benefit of the
> proposal is to make the split Build-Depends-(Indep) useful at all[1].
> Currently it is not, because the autobuilders invoke the build target,
> which in turn invokes build-arch and build-indep, so you have to put
> anything needed for building in Build-Depends, as the autobuilders
> will uselessly build the build-indep target.
>
> The -indep targets can be rather expensive, executing tex and other
> stuff and requiing installing rather big packages.
>
> I might be misunderstanding you, and you are actually asking for a
> list of packages that would benefit from the proposal.

An estimation of the number, more than a list.

> - I don't think
> that is easy to generate, as it requires checking debian/rules by
> hand, we have just libtool as example.
>         cu andreas
> [1] Currently this is only possible with ugliness like making
> build-indep an empty target and doing the actual expensive work in
> binary-indep,

Some of the packages I maintain use texi2html in the binary-indep
target (and they have texi2html in Build-Depends-Indep). Why is such
thing an ugliness? It is because it runs under root/fakeroot or are
there any other reason?

> or ignoring policy's recommendation to make build depend
> on build-arch and build-indep.

Which is what I would call complexity for very little gain.

Packages which do not benefit from a split build-arch / build-indep
(and there are certainly a lot of packages which do not benefit)
should continue to be allowed not to have such targets, without people
or policy saying they are following a "deprecated format" or anything
like that. Does this clarify my point?

What about optional fields in the control file with default values:

Build-Arch: build
Build-Indep: build

(and therefore may be omitted), but that can be overridden in this way?:

Build-Arch: build-arch
Build-Indep: build-indep

only for packages which really need or benefit from them?

(What I dislike is a "format version", mandatory conversion of all
packages to the new format in the long run, and all that).



Reply to: