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

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



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.

>> 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. 

	manoj
-- 
Eat drink and be merry, for tomorrow we diet.
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C



Reply to: