[arch-general] Build pacman statically

[Leonid Isaev]

On Fri, 3 Aug 2012 13:40:15 -0400
Calvin Morrison <mutantturkey at gmail.com> wrote:

> On 3 August 2012 13:03, Leonid Isaev <lisaev at umail.iu.edu> wrote:
> > On Fri, 3 Aug 2012 11:35:10 -0500
> > Sander Jansen <s.jansen at gmail.com> wrote:
> >
> >> On Fri, Aug 3, 2012 at 11:29 AM, Leonid Isaev <lisaev at umail.iu.edu> wrote:
> >> > On Fri, 3 Aug 2012 10:31:06 -0400
> >> > Jack Silver <jacksilver045 at gmail.com> wrote:
> >> >
> >> >> To exchange information I want to let know this list that I have
> >> >> filled a feature request form to ask for a statically builded pacman.
> >> >>
> >> >> https://bugs.archlinux.org/task/30993
> >> >>
> >> >> Comments welcome in the bug manager.
> >> >>
> >> >> جاك الفضة
> >> >
> >> > Well, bugtracker is not a place for comments, it's for solutions.
> >> >
> >> > Anyway... statically compiling things is not a way of avoiding trouble,
> >> > at least not in a self-sustained fashion. So, if you propose to have
> >> > pacman in [core] statically compiled against all needed libraries, I
> >> > would be against that as the package will be an unmaintainable mess.
> >>
> >> Why would it be a unmaintainable mess?
> >
> > Because it is _statically_ compiled so the whole binary has to be rebuilt
> > even after a minor update of one of the libraries. This is assuming that
> > you can actually make such binary with gcc...
> 
> No.
> 
> It only needs to be recompile when the compiler feels like it. If the
> perceived benefit of the newer library to link against is greater than
> the time  and energy it takes to recompile and package a product, then
> the compiler won't do it.
> 
> If curl does a minor bump fixing a function that pacman doesn't even
> use for example, we then we probably wouldn't bother. Now if it was a
> critical update then yes, we would obviously do it.

Making this decision IS a maintainance effort...

> 
> there is a whole discussion on why static linking is good on http://sta.li
> 
> Calvin

-- 
Leonid Isaev
GnuPG key: 0x164B5A6D
Fingerprint: C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://mailman.archlinux.org/pipermail/arch-general/attachments/20120803/bb42a2eb/attachment.asc>