[pacman-dev] Maybe some problems with pacman-git

[Dan McGee]

On Jan 9, 2008 11:28 AM, Aaron Griffin <aaronmgriffin at gmail.com> wrote:
> On Jan 9, 2008 11:00 AM, Dan McGee <dpmcgee at gmail.com> wrote:
> > On Jan 9, 2008 10:58 AM, Karolina Lindqvist
> > <karolina.lindqvist at kramnet.se> wrote:
> > > onsdag 09 januari 2008 skrev Aaron Griffin:
> > >
> > > > Actually, I'd prefer if the symbols were NOT in klibc. Being that this
> > > > is early-userspace, we want to minimize the size and decompression
> > > > overhead as the entire rest of the system is waiting for this to
> > > > complete.
> > > >
> > > > Assuming this is a corner case, could we set things up such that
> > > > options=(strip) forces the strip?
> > >
> > > The symbols are needed for building of klibc-extras, klibc-udev and I think,
> > > also klibc-module-init-tools.
> >
> > I think you missed the point here, Aaron. It is hard to compile
> > anything against a shared lib if it has *no symbols at all*. Actually
> > impossible as far as I know...
>
> I meant debugging symbols and all that... there was a period of time
> when they were all being built with debug enabled.
>
> > And options=(strip) would already force the strip, and that is the
> > makepkg.conf default anyway.
>
> I meant this in a different way, but now realize that it sounded
> stupid. Even forcing the strip blows things up because it detects the
> type wrong, so yeah, back to square one.

Two plans of attack here:
1. Patch makepkg with the aforementioned patch, which I find hacky as
we have gotten away from anything dealing with file extensions in
makepkg.
2. options=(!strip) in the klibc PKGBUILD, and do it manually as part
of the build function (and stripping only debug symbols).

Opinions? I don't see this as a blocker for 3.1.0 by any means as it
is such a niche case and can be solved by option #2 in the short term.
I'd prefer #2 in the long term too, but I don't want to be a dictator
here.

-Dan