Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   ArchLinux Pacman Development (http://www.linux-archive.org/archlinux-pacman-development/)
-   -   makepkg: do not attempt to strip arch agnostic packages (http://www.linux-archive.org/archlinux-pacman-development/387191-makepkg-do-not-attempt-strip-arch-agnostic-packages.html)

Andres P 06-17-2010 02:55 PM

makepkg: do not attempt to strip arch agnostic packages
 
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?

strip(1) can't take the debug symbols out of a .py last time I checked.

Seems like there's no organization. :/

Even namcap should throw an error if it finds an elf in an "-any" package.


To think I was going to propose /libexec

Andres P

Dan McGee 06-17-2010 03:26 PM

makepkg: do not attempt to strip arch agnostic packages
 
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.

> strip(1) can't take the debug symbols out of a .py last time I checked.
>
> Seems like there's no organization. :/

WTF?

> Even namcap should throw an error if it finds an elf in an "-any" package.

It does, and I wrote the damn rule. But that is not for makepkg to
decide. http://projects.archlinux.org/namcap.git/commit/?id=a121258fc2be1df8f970e09cbff889241462e491

>
> To think I was going to propose /libexec

Seriously, your attitude is going to get you nowhere on this list. We
appreciate your patches, but you can't throw a fit every time we say
something negative. I don't even know what points you are trying to
make or what agenda you are trying to push on a completely different
topic.

Address the issue your patch brings up, address the comments people
give, but don't start spewing everything else, please.

-Dan

Andres P 06-17-2010 03:51 PM

makepkg: do not attempt to strip arch agnostic packages
 
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.


And if namcap has such checks, why not makepkg?

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

Andres P

Allan McRae 06-17-2010 10:34 PM

makepkg: do not attempt to strip arch agnostic packages
 
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.

Andres P 06-18-2010 02:34 AM

makepkg: do not attempt to strip arch agnostic packages
 
On Thu, Jun 17, 2010 at 4:29 PM, Nezmer <git@nezmer.info> wrote:
> It's not a hard-to-imagine corner case. Remember that we are talking
> i[3-6]86 and x86_64 here. The latter is capable of running the former
> binaries (As far as the IS is concerned).
>
> Some OSes still use i386 low level tools (e.g for booting) in
> x86_64/AMD64 systems. That's just one example.
>
> Some projects use self-contained wine. That's another example.
>
> I can provide more examples if you wish.
>

As great as the example sounds, the vast majority of packages do not fall under
that category. Not Arch's, nor Frugal's, etc.

And for the few that do, they'll have debug symbols vs. the time gained from
not checking for them in the rest of the -any packages' makepkg run.


Until a repo reflects this necessity, it's esoteric because the situation is
far in between...

Andres P

Andres P 06-18-2010 02:44 AM

makepkg: do not attempt to strip arch agnostic packages
 
On Thu, Jun 17, 2010 at 6:04 PM, Allan McRae <allan@archlinux.org> wrote:
>> And if namcap has such checks, why not makepkg?
>
> makepkg makes packages, namcap checks packages. *The distinction seems
> clear.
>
No, it doesn't seem clear.

You know as well as I do that makepkg has a great deal of logic pertaining to
checking packages that go farther than an arch check before stripping debug
symbols.

It checks to see wether pkgver and the like have illegal characters, the same
with other fields.

With the exception of a package name starting with a '-' character, since that
check has to do with operands and calling makepkg with --pkg foo.


It's also very strange that you draw this destinction as black and white when
there's been patches posted in the last ~48 hours related to makepkg
'sanity' checks that have to do with
this very subject.

And without bringing those up; you agree with the arch check yet that's where
the whole namcap mention (and later, comparison) came in? Not making a
lot of sense.

>> 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.
>

That's well besides the point. ;)

Learning git better won't magically teach me how to sit down and sweettalk
people over the net. It seems ridiculous that I have to go out of my way
quoting man sudoers and other stupid stuff for things that I know that are
broken.

It'd be much more productive if, say, people would check what they're saying
first?

Andres P


All times are GMT. The time now is 03:28 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.