Jonathan Nieder:
> Niels Thykier wrote:
>
>> debhelper cannot see "inside" the upstream build system. If you modify
>> a .c file, debhelper won't notice and will currently just skip the
>> entire build. Alternatively, debhelper will have to invoke the build
>> system and rely on it to not be fla
Niels Thykier wrote:
> debhelper cannot see "inside" the upstream build system. If you modify
> a .c file, debhelper won't notice and will currently just skip the
> entire build. Alternatively, debhelper will have to invoke the build
> system and rely on it to not be flawed.
Yes, I think that w
Jonathan Nieder:
> Hi!
>
> Niels Thykier wrote:
>
>> [...]
>>
>> Notely, this trickery prevents you from hacking on the upstream parts
>> and use "dpkg-buildpackage -b -nc -uc -us" to reduce the build times
>> for subsequent builds. You would have to add some rm -f calls to
>> delete "internal d
Hi!
Niels Thykier wrote:
> I would like to propose that we drop or replace the following
> recommendation in Policy:
>
> """
> When a package has a configuration and build routine which takes a
> long time, or when the makefiles are poorly designed, or when build
> needs to run clean first, it is
Source: debian-policy
Severity: wishlist
Hi,
I would like to propose that we drop or replace the following
recommendation in Policy:
"""
When a package has a configuration and build routine which takes a
long time, or when the makefiles are poorly designed, or when build
needs to run clean first
5 matches
Mail list logo
