1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
Ciaran McCreesh wrote: |
5 |
| On Mon, 01 Aug 2005 14:54:04 -0700 Donnie Berkholz |
6 |
| <spyderous@g.o> wrote: |
7 |
| | Ciaran McCreesh wrote: |
8 |
| | But see, that's the thing; no packages should just generally say "Give |
9 |
| | me the X libraries" other than temporarily. They should be |
10 |
| | specifically demanding upon the exact libraries they require. |
11 |
| |
12 |
| Hrmmmmm. Is this going to be sanely doable by your average dev? How long |
13 |
| a dep string would we be having in typical cases? How about in bad |
14 |
| cases? |
15 |
|
16 |
It shouldn't be difficult in most cases, for those capable of finding |
17 |
linker lines in a build. |
18 |
|
19 |
I wrote a quick one-liner that works reasonably well on a couple of |
20 |
tests, but could use a little tweaking. Just set log to your build log |
21 |
beforehand. |
22 |
|
23 |
for linkline in $(grep ' \-l[a-zA-Z]' ${log}); do if [[ "${linkline}" =~ |
24 |
"-l[a-zA-Z]" ]]; then echo $linkline; fi; done | sort | uniq |
25 |
|
26 |
I ran it on gedit and thunderbird and got largely reasonable output. In |
27 |
gedit's case, there would be 5 |
28 |
X library dependencies. In thunderbird's case, there would be 9. |
29 |
|
30 |
| | | Is it your assumption that in the future xorg-x11 will be the only |
31 |
| | | serious X server? |
32 |
| | |
33 |
| | My assumption is that if there's another fork, it will be easier to |
34 |
| | deal with || ( xorg-libfoo forkx-libfoo ) than a virtual for every |
35 |
| | single package X provides. |
36 |
| |
37 |
| So X deps will be by package ('either xorg-libfoo or forkx-foo or |
38 |
| sgi-x'), rather than by concept in the future? |
39 |
|
40 |
This makes more sense to me, particularly given the objection people |
41 |
have to adding new virtuals. Adding a hundred or two wouldn't make them |
42 |
happy. |
43 |
|
44 |
| | | *shrug* I realise we make similar assumptions about a lot of |
45 |
| | | packages, but X is a) an at least vaguely standard protocol, b) |
46 |
| | | heavily depended upon and c) implemented by more than one vendor. |
47 |
| | |
48 |
| | Indeed. But what I've begun to discover is that virtuals aren't always |
49 |
| | the best solution when there is more than one provider, much less when |
50 |
| | that's a largely hypothetical question. |
51 |
| |
52 |
| Mmm, possibly true. For the big things though, I was hoping we could |
53 |
| switch more towards depending by concept rather than by implementation, |
54 |
| especially once we get improved virtuals. The current X situation is |
55 |
| sort of a concept dependency -- moving away from that could arguably be |
56 |
| seen as a regression from one perspective. |
57 |
|
58 |
It could be, but X is no longer a big thing. It's a few hundred small ones. |
59 |
|
60 |
Thanks for your ideas, |
61 |
Donnie |
62 |
|
63 |
-----BEGIN PGP SIGNATURE----- |
64 |
Version: GnuPG v1.4.1 (GNU/Linux) |
65 |
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org |
66 |
|
67 |
iD8DBQFC7qP6XVaO67S1rtsRAhAQAKC2hBxwGSV3RJDZaKK/bAm9fF2kDgCeP7qo |
68 |
vPyx7bXz6vKDWEEGtI4LMng= |
69 |
=ZPiY |
70 |
-----END PGP SIGNATURE----- |
71 |
-- |
72 |
gentoo-dev@g.o mailing list |