| 1 |
On Fri, Aug 31, 2012 at 6:42 AM, Michał Górny <mgorny@g.o> wrote: |
| 2 |
> |
| 3 |
> So please introduce virtual/compiler, virtual/linker, |
| 4 |
> virtual/posix-system, virtual/sratatata and add them to DEPEND of every |
| 5 |
> single ebuild. |
| 6 |
|
| 7 |
Every ebuild doesn't need all of those - that is the whole point. As |
| 8 |
Duncan already pointed out, reducing @system is a goal, but it doesn't |
| 9 |
mean that we need to get there overnight. However, we'll never get |
| 10 |
there if we keep going backwards. |
| 11 |
|
| 12 |
> |
| 13 |
> I believe that the more important direction here is to make development |
| 14 |
> *easier*, not harder. Adding the same DEPENDs over and over again to |
| 15 |
> every single package is at least frustrating. |
| 16 |
|
| 17 |
This isn't needed by every single package either. I'm all for tools |
| 18 |
that help automate DEPEND population, and I'm fine with having an |
| 19 |
ebuild template that includes "gotcha" depends pre-populated so that |
| 20 |
devs give them consideration (and deleting lines is easier than adding |
| 21 |
them). |
| 22 |
|
| 23 |
> Similarly frustrating |
| 24 |
> would be if those 'reduced systems' had to rebuild gcc every time they |
| 25 |
> wanted to compile something... oh wait, they would have to bootstrap it |
| 26 |
> every time. |
| 27 |
> |
| 28 |
|
| 29 |
I would think that somebody running a reduced system would be likely |
| 30 |
to be installing binary packages, or use a binary package of gcc, etc. |
| 31 |
Presumably they knew what they're getting into and for whatever |
| 32 |
reason the balance was considered acceptable for them. I would think |
| 33 |
that the sorts of people who would run reduced systems would probably |
| 34 |
not be updating them frequently anyway. |
| 35 |
|
| 36 |
There are also other benefits of reduced @system besides running a |
| 37 |
reduced system. |
| 38 |
|
| 39 |
Rich |
Archives