linux-api-headers-2.6.32.5-1
- rename kernel-headers - too similar to kernel26-headers (FS#17655)
- convert to arch=any (built on x86_64, tested on i686)
- delete useless install files (FS#17641)
- bump to latest patch-set

Diffing the package shows that updating the patch-set does not require a
toolchain rebuild.


Signoff,
Allan

On Sun, 2010-01-24 at 12:13 +1000, Allan McRae wrote:
> linux-api-headers-2.6.32.5-1
> - rename kernel-headers - too similar to kernel26-headers (FS#17655)
> - convert to arch=any (built on x86_64, tested on i686)
> - delete useless install files (FS#17641)
> - bump to latest patch-set
>
> Diffing the package shows that updating the patch-set does not require a
> toolchain rebuild.

Works fine here, but one sidenote. These headers are
architecture-dependent. For i686/x86_64 there's no problem, as both
share the same architecture in the kernel tree, but installing this on
PPC will make compiling packages impossible.

On 25/01/10 17:41, Jan de Groot wrote:

On Sun, 2010-01-24 at 12:13 +1000, Allan McRae wrote:

linux-api-headers-2.6.32.5-1
- rename kernel-headers - too similar to kernel26-headers (FS#17655)
- convert to arch=any (built on x86_64, tested on i686)
- delete useless install files (FS#17641)
- bump to latest patch-set

Diffing the package shows that updating the patch-set does not require a
toolchain rebuild.


Works fine here, but one sidenote. These headers are
architecture-dependent. For i686/x86_64 there's no problem, as both
share the same architecture in the kernel tree, but installing this on
PPC will make compiling packages impossible.


Good point. I had thought about this and decided that they we
architecture independent on the architectures we support so went with
arch=any. Should I revert that?


Allan

On Mon, Jan 25, 2010 at 1:46 AM, Allan McRae <allan@archlinux.org> wrote:
> On 25/01/10 17:41, Jan de Groot wrote:
>>
>> On Sun, 2010-01-24 at 12:13 +1000, Allan McRae wrote:
>>>
>>> linux-api-headers-2.6.32.5-1
>>> * - rename kernel-headers - too similar to kernel26-headers (FS#17655)
>>> * - convert to arch=any *(built on x86_64, tested on i686)
>>> * - delete useless install files (FS#17641)
>>> * - bump to latest patch-set
>>>
>>> Diffing the package shows that updating the patch-set does not require a
>>> toolchain rebuild.
>>
>> Works fine here, but one sidenote. These headers are
>> architecture-dependent. For i686/x86_64 there's no problem, as both
>> share the same architecture in the kernel tree, but installing this on
>> PPC will make compiling packages impossible.
>
> Good point. *I had thought about this and decided that they we architecture
> independent on the architectures we support so went with arch=any. *Should I
> revert that?

A comment in the PKGBUILD would probably be nice even if you don't
revert it alluding to the above. That way anyone trying to do some abs
cross-compile could at least have something to go off of. However,
with that logic, making it not arch-independent would help them even
more...

-Dan

On Mon, 25 Jan 2010 08:37:17 -0600
Dan McGee <dpmcgee@gmail.com> wrote:

> On Mon, Jan 25, 2010 at 1:46 AM, Allan McRae <allan@archlinux.org>
> wrote:
> > On 25/01/10 17:41, Jan de Groot wrote:
> >>
> >> On Sun, 2010-01-24 at 12:13 +1000, Allan McRae wrote:
> >>>
> >>> linux-api-headers-2.6.32.5-1
> >>> * - convert to arch=any *(built on x86_64, tested on i686)
> [...]
> > Good point. *I had thought about this and decided that they we
> > architecture independent on the architectures we support so went
> > with arch=any. *Should I revert that?
>
> A comment in the PKGBUILD would probably be nice even if you don't
> revert it alluding to the above. That way anyone trying to do some abs
> cross-compile could at least have something to go off of. However,
> with that logic, making it not arch-independent would help them even
> more...
>
> -Dan

+1 for not arch-independent

Community projects for different architectures are coming up all the
time. Also, ARM is gaining a stronghold on netbooks, a perfect target
for Arch. ARM might very well become a new official architecture in a
few years, if it really takes of (the way I hope ).

Why introduce (subtle) stumbling blocks to save less than 1M on mirrors?

Jinks