| 1 |
On Tuesday 23 September 2008 22:44:35 Alexis Ballier wrote: |
| 2 |
> > > False. If for instance coolfeature was made optional in >=pv you |
| 3 |
> > > can use logic like: |
| 4 |
> > > |
| 5 |
> > > if has_version '>=cat/foo-pv' && ! has_version |
| 6 |
> > > 'cat/foo[coolfeature]'; then ewarn '...' |
| 7 |
> > > fi |
| 8 |
> > |
| 9 |
> > I think this should cover all the current functionality with |
| 10 |
> > built_with_use. |
| 11 |
> |
| 12 |
> This is just an ugly hack. Think about a package that has coolfeature |
| 13 |
> useflag removed and enabled by default for a couple of releases because |
| 14 |
> it wouldn't build without it and once upstream sorted out everything |
| 15 |
> the useflag is coming back. Missing useflags that are assumed to be |
| 16 |
> enabled have nothing to do with the package version being greater than |
| 17 |
> a given number. |
| 18 |
|
| 19 |
If it is needed that often we should add support for stating the state of the |
| 20 |
use flag in dependencies. With the currently planned eapi 2 you get |
| 21 |
dependencies such as: |
| 22 |
|
| 23 |
DEPEND="|| ( >=cat/foo-pv[coolfeature] <cat-foo-pv )" |
| 24 |
|
| 25 |
too. Doing the same with has_version is only consistent with that. If we add |
| 26 |
support for it in dependency syntax it will work with has_version too... |
| 27 |
|
| 28 |
-- |
| 29 |
Bo Andresen |
Archives