Re: Build pacman statically

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On Fri, 3 Aug 2012 13:40:15 -0400
Calvin Morrison <mutantturkey@xxxxxxxxx> wrote:

> On 3 August 2012 13:03, Leonid Isaev <lisaev@xxxxxxxxxxxx> wrote:
> > On Fri, 3 Aug 2012 11:35:10 -0500
> > Sander Jansen <s.jansen@xxxxxxxxx> wrote:
> >
> >> On Fri, Aug 3, 2012 at 11:29 AM, Leonid Isaev <lisaev@xxxxxxxxxxxx> wrote:
> >> > On Fri, 3 Aug 2012 10:31:06 -0400
> >> > Jack Silver <jacksilver045@xxxxxxxxx> 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

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux