| 1 |
On Wed, Jun 11, 2008 at 04:20:04AM +0100, Ciaran McCreesh wrote: |
| 2 |
> On Tue, 10 Jun 2008 19:56:23 -0700 |
| 3 |
> Brian Harring <ferringb@×××××.com> wrote: |
| 4 |
> > * easy to shoehorn in for any profile.bashrc compliant manager |
| 5 |
> > (portage/pkgcore); realize paludis is left out here (via it |
| 6 |
> > intentionally being left out of PMS atm by ciaran), but |
| 7 |
> > profile.bashrc *is* used by ebuild devs, thus it's a viable course (I |
| 8 |
> > don't see profile.bashrc ever going away basically). |
| 9 |
> |
| 10 |
> If profile.bashrc is to be kept, it means massively reducing what can |
| 11 |
> be done in there. |
| 12 |
|
| 13 |
Restraint in use of profile.bashrc is a per community QA measure, not |
| 14 |
a format restriction- think through the other "this is better for QA" |
| 15 |
things I've suggested PMS wise, you've responded in the same manner. |
| 16 |
|
| 17 |
|
| 18 |
> > * doesn't address versioning changes. |
| 19 |
> |
| 20 |
> Or indeed any change where the ebuild can't be visible to older package |
| 21 |
> managers without breaking them. |
| 22 |
> |
| 23 |
> So basically it's not a solution at all. |
| 24 |
|
| 25 |
Name a scenario. |
| 26 |
|
| 27 |
Note, if the scenario is "pm doesn't support eapi function, and |
| 28 |
doesn't support profile.bashrc", skip it, you're repeating what I |
| 29 |
already laid out (which results in visible bash complaints, but the |
| 30 |
manager still labeling the eapi inoperable). |
| 31 |
~harring |
Archives