[pacman-dev] [PATCH 03/11] makepkg: do not attempt to strip arch agnostic packages

[Allan McRae]

On 18/06/10 01:51, Andres P wrote:
> On Thu, Jun 17, 2010 at 10:56 AM, Dan McGee<dpmcgee at gmail.com>  wrote:
>> On Thu, Jun 17, 2010 at 9:55 AM, Andres P<aepd87 at gmail.com>  wrote:
>>> On Thu, Jun 17, 2010 at 9:56 AM, Dan McGee<dpmcgee at gmail.com>  wrote:
>>>> This is one of those "seems like a good idea but why" patches. Yes,
>>>> we'll save milliseconds in building a package, but what if someone has
>>>> a legit reason for putting libraries or binaries in an 'any' package?
>>>> I'm going to -1 this one.
>>>>
>>> But "any" means that there's no arch dependant code in the package?
>>
>> No, it means the package is able to be installed on any architecture
>> and work as intended. What if I had an "elf-demo" package that
>> contained different ELF files from multiple architectures? Yes,
>> contrived, but possible.
>>
>
> And for that corner case, people that have split in the opts array
> have to run it against -any packages that, suffice to say, are
> probably not going to benefit from the exception.
>
> So you're creating a what if for the least possible scenario.

This patch enforces no stripping on a arch=any package.  All it takes is 
one real work exception to the thinking that arch=any packages can not 
contain binaries and then we would need to revert that patch.

Saying that, even the contrived examples present in this thread so far 
should not have the host system strip used on the binaries so you 
require options=(!strip) added to the PKGBUILD anyway.  So I am leaning 
in favour of including that patch until someone presents an actual case 
where it is wrong.

> And if namcap has such checks, why not makepkg?

makepkg makes packages, namcap checks packages.  The distinction seems 
clear.

> It just gets very tedious to mantain a makepkg-ng on the side.

Then you need to learn to use git better.  I maintained a patch set for 
at least six months in the last release cycle before they got accepted 
into mainline.