Re: Stop shipping static libraries for NetBSD

["Greg A. Woods; Planix, Inc." <woods%planix.ca@localhost>]

On 19-Aug-08, at 7:03 PM, James Chacon wrote:

> On Aug 19, 2008, at 5:47 PM, Aaron J. Grier wrote:
>
> > On Tue, Aug 19, 2008 at 03:32:38PM -0400, Greg A. Woods; Planix,  
> > Inc. wrote:
> > > On 19-Aug-08, at 3:13 PM, Aaron J. Grier wrote:
> > > >
> >
> > again with the binary-only strawman.  I do not understand how you get
> > from simplifying the build process by eliminating .a files to in
> > marketing perceptions and proprietary OS vendors.  perhaps you could
> > elucidate.
> >
> > let me see if I can summarize your argument:
> >
> > - user must be binary-only OS consumer
> > AND
> > - user must be source application consumer
> > AND
> > - user must be interested in statically-linking source applications
>
> AND
> user must be able to compile his own source but somehow cannot  
> possibly compile/obtain NetBSD source
>
> Otherwise in Greg's world the user would simply be able to compile  
> both ends of whatever this user wants and have no issue at all.

Obviously you guys haven't spent much time working around GNU/Linux  
users lately.  (or open solaris users for that matter)

Some folks will be willing and able to blindly type "configure && make  
install" and some folks will even write their own code, but not all  
those folks, in fact the vast majority in both those camps, will be  
willing and able to rebuild their entire OS from scratch with the  
custom options necessary to get static libraries installed, _even_ if  
it is NetBSD and it continues to be as easy to build as it is today.   
As others have clearly stated, some of those users will want to at  
least try static linking sometimes, even if they don't always  
understand why.

Meanwhile what you guys are foisting is the real straw-man argument.   
Why stop shipping static libraries when they can be, and indeed  
probably still _must_ be, built during a system build?  Why use such  
stupid and lame arguments such as PAM (and maybe CITRUS) to bolster  
this proposal?  Why ignore all the real issues with _forced_ dynamic  
runtimes?  Nobody has managed to give any real technical evaluation  
showing any real, i.e. as opposed to straw-man, arguments in favour of  
_forced_ dynamic runtime.

--
                                        Greg A. Woods; Planix, Inc.
                                        <woods%planix.ca@localhost>