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

Bug#374029: Fixing inconsisten and unusefull Build-Depends/Conflicts definition

Manoj Srivastava <srivasta@debian.org> writes:

> On 18 Jun 2006, Goswin von Brederlow outgrape:
>> Peter Eisentraut <peter_e@gmx.net> writes:
>>> Goswin von Brederlow wrote:
>>>> On the other hand the savings can be huge. Think about how many
>>>> packages install latex and fonts and generate the documentation
>>>> needlessly during build. Installing and purging latex as well as
>>>> all the initex runs and font generation takes up a awfull lot of
>>>> time
>>> I think most packages build their documentation or other
>>> architecture-independent parts as part of a general make/make
>>> install process, so it's not possible to create useful separate
>>> build-arch and build-indep targets.
>> A lot of software has a doc dir and it is relatively simple to
>> seperate recursing into doc from the rest. Unless the build-*
>> targets become actually usefull nobody will put any work into
>> splitting the build process into arch and indep parts though.
>         Umm. Most of my packages I can simply call "make" or "ake
>  build" and let upstream  Makefiles build stuff -- which means that if
>  the arch indep part is split of changed (./scripts dir, for example),
>  I do not have to change my rules file to follow suit. In this case,
>  splitting the buiild process into arch and indep parts is not trivial.

I would think "make" will always do the customary "all" and include
docs and such. But what stops you from having a "make binary" to
compile and "make doc" in the Makefile? Yes you need to change the
makefile and debian/rules but it usualy isn't that hard.

>>> Looking at the archive right now, there are only 129 source
>>> packages (in testing) that are not Architecture: all and declare
>>> Build-Depends-Indep (and quite a few of those are obviously wrong).
>>> So it seems to be a limited problem.  However, if your concern is
>>> mostly to reduce installation time of documentation tools, then the
>>> current Build-Depends/Build-Depends-Indep setup seems to work quite
>>> well.  I don't see where Build-Depends-Arch would fit in there.
>> The problem currently is that it isn't even possible to seperate
>> them even if the makefile suports it because the build target must
>> be called. The proposal is as much a clarification and extension of
>> the Build-Depends* fields as a mechanism to detect and use build-*
>> targets. Only then can one split arch and indep building and have a
>> meaningfull Build-Depends-Indep.
>         I think the way to do this is to make the build target depend
>  on build-arch and build-indep, so calling build builds everything,
>  but allows for a future improvement in efficiency. Assuming, of
>  course, that  upstream build process also allows for this split up. 

We already have that like forever. This is not helping at all since
you can't detect the existance of build-arch/indep in the makefile
correctly and thus dpkg-buildpackage can never call it. So you always
call build and always need all Build-Depends for arch and indep
building. THAT is the core problem. 

> 	manoj


Reply to: