| 1 |
On Wed, Aug 03, 2011 at 10:28:51PM +0100, Ciaran McCreesh wrote: |
| 2 |
> On Wed, 3 Aug 2011 14:26:56 -0700 |
| 3 |
> Brian Harring <ferringb@×××××.com> wrote: |
| 4 |
> > Aka, ebuild's should be written to assume the files they install get |
| 5 |
> > wiped; there is *zero* mention of mtime, nor could any ebuild rely on |
| 6 |
> > it and be compliant. |
| 7 |
> |
| 8 |
> But as it's a FEATURE, they can't assume that at all. |
| 9 |
|
| 10 |
It's outside the ebuild's area of concern (think seperation of |
| 11 |
concerns), just the same as INSTALL_MASK. The ebuild, per spec, |
| 12 |
should be written to assume it's wiped. |
| 13 |
|
| 14 |
If the user overrides portages make.globals setting FEATURES=unmerge-orphans |
| 15 |
it is on the *users* head to maintain the fallout, just the same as if |
| 16 |
they go and set INSTALL_MASK to do something special. |
| 17 |
|
| 18 |
|
| 19 |
> So either we spec VDB and the unmerge process, which gets horrible for |
| 20 |
> all kinds of reasons, or ebuilds can't assume that things that have |
| 21 |
> been modified get wiped. |
| 22 |
|
| 23 |
This is getting more into "the sky is falling" territory. If you'd |
| 24 |
like to tighten the spec, go nuts, but there isn't anything to see |
| 25 |
here nor is there a real issue. |
| 26 |
|
| 27 |
This really is no different than INSTALL_MASK. |
| 28 |
~brian |
Archives