1 |
On Monday, September 19, 2011 10:57:30 Michał Górny wrote: |
2 |
> On Mon, 19 Sep 2011 10:43:04 -0400 Mike Frysinger wrote: |
3 |
> > On Monday, September 19, 2011 03:10:45 Michał Górny wrote: |
4 |
> > > On Sun, 18 Sep 2011 18:39:32 -0400 Mike Frysinger wrote: |
5 |
> > > > On Sunday, September 18, 2011 18:16:30 Nirbheek Chauhan wrote: |
6 |
> > > > > On Mon, Sep 19, 2011 at 2:25 AM, Michał Górny wrote: |
7 |
> > > > > > '$(use_enable static-libs static)' themselves. While at it, it |
8 |
> > > > > > may be better to just drop the flag if no other package |
9 |
> > > > > > relies on it and no user has ever requested the static build |
10 |
> > > > > > of that package. |
11 |
> > > > > |
12 |
> > > > > I don't see any harm with including IUSE="static-libs" for every |
13 |
> > > > > package that has working/usable static libraries[1]. Why wait |
14 |
> > > > > for users to request it on bugzilla when it's a near-zero-cost |
15 |
> > > > > and zero-maintenance to add it to ebuilds? |
16 |
> > > > |
17 |
> > > > i missed this sentence from Michał's e-mail. unconditionally not |
18 |
> > > > building static libraries is against policy. if you install |
19 |
> > > > shared libs that get linked against, then you must provide static |
20 |
> > > > libraries unconditionally as well or support IUSE=static-libs. |
21 |
> > > > maintainers do not get to choose "no one has asked for it and no |
22 |
> > > > one in the tree is using it thus my ebuild isnt going to". |
23 |
> > > |
24 |
> > > Where is that policy? |
25 |
> > |
26 |
> > this policy predates much of the documentation process and is missed |
27 |
> > by the developer handbook. it is however mentioned explicitly in the |
28 |
> > devmanual. |
29 |
> |
30 |
> So, it a policy which even QA doesn't recall. |
31 |
|
32 |
i cant speak for random developers who either (a) haven't been around (b) |
33 |
formed their own opinion (c) don't care (d) are forgetful or (e) some list of |
34 |
the above or other items. it doesn't change the policy which long predates |
35 |
the existence of the QA team. |
36 |
|
37 |
> It seems worth changing as there is really no reason to randomly install |
38 |
> every possible static library out there if system does support and use |
39 |
> shared linking. |
40 |
|
41 |
just because you don't care about static linking doesn't matter. many people |
42 |
do, many packages rely on it, and the overhead to support it is trivial. if |
43 |
you dislike static libraries in your packages, then update them to respect |
44 |
USE=static-libs. |
45 |
|
46 |
> > > AFAIK the policy was to 'follow upstream' which |
47 |
> > > usually means 'shared only'. I really don't see a reason to build |
48 |
> > > static libtorrent as upstream even doesn't support static linking. |
49 |
> > |
50 |
> > by that token, i'll go ahead and remove glibc's static libraries |
51 |
> > since upstream doesn't even support static linking |
52 |
> |
53 |
> I'm probably ignorant so you'd have to elaborate more on that to make |
54 |
> me see a problem there. |
55 |
|
56 |
think about it a little bit. your system is using static binaries right now, |
57 |
and considering you like to push systemd + initramfs so much, i would have |
58 |
thought you'd realize the implications more quickly. |
59 |
-mike |