| 1 |
On Thu, Oct 06, 2005 at 02:14:32PM +1000, Finn Thain wrote: |
| 2 |
> |
| 3 |
> |
| 4 |
> On Wed, 5 Oct 2005, Kito wrote: |
| 5 |
> |
| 6 |
> [snip] |
| 7 |
> > |
| 8 |
> > My first question would be how to identify ebuilds that respect ${prefix}? |
| 9 |
> > |
| 10 |
> > A separate profile/keyword seems wrong. |
| 11 |
> > |
| 12 |
> > ICANINSTALLTO was the best idea presented, but that implies it would be |
| 13 |
> > a list of known working prefixes, which seems unrealistic. |
| 14 |
> |
| 15 |
> What problem was ICANINSTALLTO intended to solve? IIRC, it was discussed |
| 16 |
> on -dev in the context of vim plug-ins. Apart from vim plugins, has anyone |
| 17 |
> found other problem packages? |
| 18 |
> |
| 19 |
> I'm wondering, would a constraint to the effect that "certain deps of pkg |
| 20 |
> foo must be on the same prefix as foo" suffice for the vim plugin case? |
| 21 |
> |
| 22 |
> Or maybe that would work better if expressed, "pkg blah can not satisfy a |
| 23 |
> dep from any pkg on a different prefix". Such constraints would be |
| 24 |
> possible to implement with a new file in the profile (say, package.local). |
| 25 |
That gets into more of ciaran's HOME installation target feature. |
| 26 |
Current form for global prefix offset is |
| 27 |
DOMAIN="root offset" , with offset == prefix offset. |
| 28 |
|
| 29 |
If an ebuild doesn't have DOMAIN="offset", and you're doing a prefix |
| 30 |
offset, it's unusable. No question of "can I use a dep from another |
| 31 |
prefix", with prefix offset you're doing the deps full in an offset. |
| 32 |
|
| 33 |
As stated earlier in this mess of a thread, HOME crap is being left to |
| 34 |
those who want it, it'll be implemented by those who want it after |
| 35 |
global prefix is ironed out (if it is accepted also). |
| 36 |
~harring |
Archives