| 1 |
On Thursday 30 March 2006 11:40, Marius Mauch wrote: |
| 2 |
> On Thu, 30 Mar 2006 08:30:17 +0900 |
| 3 |
> Jason Stubbs <jstubbs@g.o> wrote: |
| 4 |
> |
| 5 |
> > On Thursday 30 March 2006 01:21, Marius Mauch wrote: |
| 6 |
> > > Marius Mauch schrieb: |
| 7 |
> > > > So after manifest2 is in, I'll revive the other issue that IMO is |
| 8 |
> > > > a requirement for 2.1: enforcing dependencies needed to use the |
| 9 |
> > > > tree (see old threads or glep44 for reasoning). |
| 10 |
> > |
| 11 |
> > Can you summarise the reasoning again please? |
| 12 |
> |
| 13 |
> a) avoid massive breakage when certain new features are introduced |
| 14 |
> (past examples being cascading profiles or new-style virtuals) |
| 15 |
|
| 16 |
I can't see how massive breakage can be avoided. With your patch the only |
| 17 |
difference is instead of partial breakage it's something like "your system |
| 18 |
is likely broken so go and visit some page to find out if it really is and |
| 19 |
how you can fix it." |
| 20 |
|
| 21 |
> b) similar to a) allow people to use new features without having to |
| 22 |
> wait for a year or two |
| 23 |
|
| 24 |
Why not just always force portage to be upgraded to at least the latest |
| 25 |
stable version? The user can override it by masking (although there isn't |
| 26 |
ever any need to as portage doesn't affect other software). If the ebuild |
| 27 |
environment is properly documented, things such as new bash features can |
| 28 |
be tied to EAPI. Using EAPI on portage ebuilds themselves, a clear upgrade |
| 29 |
path can be designated and maintained within the tree. |
| 30 |
|
| 31 |
With EAPI and forced portage upgrades, the only thing that isn't covered |
| 32 |
is profile "masking". However, your patch doesn't really cover that either. |
| 33 |
Unless I'm missing how that would be covered? |
| 34 |
|
| 35 |
-- |
| 36 |
Jason Stubbs |
| 37 |
-- |
| 38 |
gentoo-portage-dev@g.o mailing list |
Archives