| 1 |
On Fri, 31 Aug 2012 14:56:06 -0400 |
| 2 |
Mike Gilbert <floppym@g.o> wrote: |
| 3 |
|
| 4 |
> On Fri, Aug 31, 2012 at 2:16 PM, Duncan <1i5t5.duncan@×××.net> wrote: |
| 5 |
> > Thus, not adding it to @system in no way means it's not considered |
| 6 |
> > mandatory for a normal install, it just means the ultimate goal is |
| 7 |
> > to have all the deps specified and nothing left in @system, and |
| 8 |
> > while progress isn't fast by a long shot, the first thing is to |
| 9 |
> > ensure we're not regressing! |
| 10 |
> > |
| 11 |
> |
| 12 |
> If the ultimate goal is to eliminate @system entirely (which it |
| 13 |
> probably isn't), we will need to revisit the way stage building works. |
| 14 |
> If understand correctly, a stage3 contains @system and its |
| 15 |
> dependencies. |
| 16 |
> |
| 17 |
> The smallest you can really make @system under that circumstance would |
| 18 |
> be a working toolchain and the utilities necessary to build any other |
| 19 |
> needed packages. I think that is the goal that most people have been |
| 20 |
> shooting for lately. |
| 21 |
|
| 22 |
But you are aware that this will practically mean that there could be |
| 23 |
no stand-alone ebuild repository because fulfilling the ebuild |
| 24 |
dependencies wouldn't be anymore possible without providing all |
| 25 |
of the standard system components, including those specified as |
| 26 |
required by the PMS? |
| 27 |
|
| 28 |
That in turn will make PMS utility requirements (bash, GNU find |
| 29 |
etcetera) completely useless because the ebuilds will have to request |
| 30 |
them explicitly anyway. But hey, you're aware that ebuilds use some of |
| 31 |
those tools in global scope, before DEPEND is fulfilled? Also, I don't |
| 32 |
think we have any kind of 'build'-time dependencies for binary |
| 33 |
packages... |
| 34 |
-- |
| 35 |
Best regards, |
| 36 |
Michał Górny |
Archives