1 |
On Tuesday, August 23, 2011 13:53:26 Michael wrote: |
2 |
> Mike Frysinger wrote: |
3 |
> > On Monday, August 22, 2011 15:21:23 Michael wrote: |
4 |
> >> I wrote a script to search for discrepancies between linked libraries |
5 |
> >> and what's defined in (R)DEPEND, with the intention of improving QA for |
6 |
> >> minimal package installs. |
7 |
> >> |
8 |
> >> The devmanual seems to suggest that it's a bad thing for packages to |
9 |
> >> explicitly depend on packages in the system set, while many packages in |
10 |
> >> the tree do indeed explicitly depend upon packages such as zlib and |
11 |
> >> ncurses. |
12 |
> > |
13 |
> > file bugs for missing zlib/ncurses deps. if there are other packages |
14 |
> > you're concerned with, ask now and we'll tell you. |
15 |
> |
16 |
> What about packages such as bzip2, xz-utils, or really, app-arch/*? |
17 |
|
18 |
assuming you're referring to them because the SRC_URI is compressed by the |
19 |
relevant formats, atm only bzip2 and gzip is allowed to be assumed. |
20 |
everything else has to be in DEPEND. there is work/discussion to automate |
21 |
this (implicit unpack depends based on SRC_URI suffixes). |
22 |
|
23 |
if your package is actually linking against any of the libs these guys |
24 |
provided (like libbz2.so), then you need to treat it like any other link-time |
25 |
dependency. |
26 |
|
27 |
> Also, on a related note, would it be appropriate to report the following |
28 |
> undeclared deps, given that the package in question already has DEPEND for |
29 |
> gtk+? |
30 |
|
31 |
like Nathan said, only if the package directly uses/links against the X11 |
32 |
API/libs in question. if the package only uses gtk+ funcs, then it should not |
33 |
be declaring a dependency on the X11 libs. |
34 |
|
35 |
keep in mind that an app that only uses the gtk api can run on a system where |
36 |
gtk is not using X11 as its backend. think raw framebuffer, win32, or |
37 |
something equally ridiculous. |
38 |
-mike |