1 |
I'd probably just run a cron job every hour or so to delete these files. |
2 |
|
3 |
But it would be nice there was an additional emerge option that if when |
4 |
paired with -b or -B would not include the includes or static libraries. |
5 |
|
6 |
jbw |
7 |
|
8 |
Mike Culbertson wrote: |
9 |
> Does anyone know of an existing way in which to not include development |
10 |
> related files in binary package builds, so as to generate packages that would |
11 |
> be more apprpriate for a server? |
12 |
> |
13 |
> Case in point, I have an NFS server that neither builds it's own packages nor |
14 |
> does it have any use for any headers or static libraries (or even gcc for |
15 |
> that matter). I can manually remove stuff from /usr/include, /usr/lib/*.a, |
16 |
> etc but next round of upgrades and all the dev related files would be back, |
17 |
> so it would be very handy to generate packages that did not have the files to |
18 |
> begin with. |
19 |
> |
20 |
> From what I've seen, I have a few current options: |
21 |
> |
22 |
> 1) custom ebuilds - this would be a bit of a management nightmare |
23 |
> 2) system imager - in progress, but I would rather have the control at the |
24 |
> package level since the "golden client" would still need to be fixed. |
25 |
> 3) scripts that clean files after package installs - again, it would be nice |
26 |
> not to have any files to clean rather than to delete them after the fact. |
27 |
> |
28 |
> Any of these is do-able in one context or another, but they still remain as a |
29 |
> way to override what is installed with a package, rather than remedying the |
30 |
> package itself. |
31 |
> |
32 |
> Does anyone have something more elegant or perhaps know of tools that can |
33 |
> control the contents of a binary package without having to manually manage |
34 |
> the ebuild? |
35 |
> |
36 |
> TIA |
37 |
> |
38 |
> Mike Culbertson |