On 18/06/10 01:51, Andres P wrote:
On Thu, Jun 17, 2010 at 10:56 AM, Dan McGee<dpmcgee@gmail.com> wrote:
On Thu, Jun 17, 2010 at 9:55 AM, Andres P<aepd87@gmail.com> wrote:
On Thu, Jun 17, 2010 at 9:56 AM, Dan McGee<dpmcgee@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.