| 1 |
Am Mittwoch, den 25.03.2009, 23:23 +0000 schrieb Ciaran McCreesh: |
| 2 |
> On Wed, 25 Mar 2009 23:06:37 +0100 |
| 3 |
> Donnie Berkholz <dberkholz@g.o> wrote: |
| 4 |
> > > 9) EAPI 3 bans || ( use? ( ... ) ) |
| 5 |
> > |
| 6 |
> > What is the suggested replacement? If there's a decent one, sure. |
| 7 |
> |
| 8 |
> The replacement is to write the deps out correctly. Every single use of |
| 9 |
> || ( use? ( ... ) ) in the tree is wrong. |
| 10 |
I created bug #262297 for that (with more text, featuring a citation |
| 11 |
from a famous non-gentoo-dev ;-). |
| 12 |
|
| 13 |
> |
| 14 |
> > > 2) EAPI 3 supports slot operator dependencies |
| 15 |
> > |
| 16 |
> > Was this for bug #229521? If so, sure. |
| 17 |
> |
| 18 |
> Yup. I'm avoiding the term 'multi-slot', though, since that's not what |
| 19 |
> this is and we're already using multi- in relation to slots for the |
| 20 |
> non-static SLOT idea. |
| 21 |
> |
| 22 |
> > > 10) dohard and dosed banned in EAPI 3 |
| 23 |
> > |
| 24 |
> > I think I missed the reasoning for removing these, particularly |
| 25 |
> > dosed. pybugz didn't see any open bugs. |
| 26 |
> |
| 27 |
> Portage doesn't merge hardlinks correctly, so dohard is bad. |
| 28 |
And there's at least one ebuild in the tree which tries to create a |
| 29 |
hardlink across multiple directories and there fails if those are on |
| 30 |
separate volumes |
| 31 |
|
| 32 |
> And |
| 33 |
> dosed's been considered deprecated for years. |
| 34 |
I've been taught so as well. |
| 35 |
|
| 36 |
|
| 37 |
> |
| 38 |
> > > 11) doinclude, newinclude for EAPI 3 |
| 39 |
> > |
| 40 |
> > Is installing to /usr/include by default useful for most packages |
| 41 |
> > that want to use this? Or would they /usr/include/${PN}? If you have |
| 42 |
> > to change it often, aren't you just as well off using insinto/doins? |
| 43 |
> > Should there be an "includeinto"? |
| 44 |
> I'd be inclined to agree on that one, but people seem to be after more |
| 45 |
> of these do* things. |
| 46 |
Would it be possible that doinclude could also strip "+x" from |
| 47 |
permission bits? I encountered quiet a few packages having +x set for |
| 48 |
whatever reason and I had to change that manually. |
| 49 |
|
| 50 |
> |
| 51 |
> |
| 52 |
> > > 21) REPLACING_VERSIONS and REPLACED_BY_VERSION in EAPI 3 |
| 53 |
> > |
| 54 |
> > I'm curious why it isn't global. Seems like it would make sense to |
| 55 |
> > put it near dependencies. Also I could be wrong, but wouldn't you |
| 56 |
> > want to be able to cache this and show smart pretend output, etc? |
| 57 |
> |
| 58 |
> I think you're misunderstanding what this is for. It's to allow |
| 59 |
> packages to work out whether they're upgrading / downgrading / |
| 60 |
> reinstalling / whatever, since Zac broke the devmanual-documented and |
| 61 |
> PMS-required way of doing it using has_version and refuses to revert it. |
| 62 |
> |
| 63 |
... and this also more or less explains why it's only available in some |
| 64 |
phases. What must be said here is that REPLACING_VERSIONS and |
| 65 |
REPLACED_BY_VERSION in pkg_pretend and pkg_setup must be used carefully |
| 66 |
since they may or may not be defined in those phases and there's also no |
| 67 |
way to guarantee it (think of binary packages). |
Archives