On 18/06/10 01:51, Andres P wrote:
On Thu, Jun 17, 2010 at 10:56 AM, Dan McGee<[email protected]> wrote:
On Thu, Jun 17, 2010 at 9:55 AM, Andres P<[email protected]> wrote:
On Thu, Jun 17, 2010 at 9:56 AM, Dan McGee<[email protected]> 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.
