| 1 |
On Tue, Aug 08, 2006 at 08:33:51AM +0100, Ciaran McCreesh wrote: |
| 2 |
> On Tue, 8 Aug 2006 00:22:50 -0700 Brian Harring <ferringb@×××××.com> |
| 3 |
> wrote: |
| 4 |
> | On Tue, Aug 08, 2006 at 07:23:31AM +0100, Ciaran McCreesh wrote: |
| 5 |
> | > On Mon, 7 Aug 2006 21:41:39 -0700 Brian Harring <ferringb@×××××.com> |
| 6 |
> | > wrote: |
| 7 |
> | > | > The use.force feature is complementary to use.mask. It's |
| 8 |
> | > | > exactly the same concept, but inverted. |
| 9 |
> | > | |
| 10 |
> | > | And both files _should_ be implemented via use deps. |
| 11 |
> | > |
| 12 |
> | > Huh? How? |
| 13 |
> | |
| 14 |
> | forcing cxx on via package.mask for gcc |
| 15 |
> | sys-devel/gcc[-cxx] |
| 16 |
> | |
| 17 |
> | forcing it off |
| 18 |
> | sys-devel/gcc[cxx] |
| 19 |
> |
| 20 |
> Mmm. See, that'll lead to error messages if the user sets USE=cxx and |
| 21 |
> then tries to install gcc. With the .mask/.force, it's handled |
| 22 |
> automatically and indicated visibly by use flags being (parened). |
| 23 |
|
| 24 |
The error msg would be "blah is masked", with an explanation of why. |
| 25 |
Pretty standard fair, portage already does the same now for non use |
| 26 |
dep maskings. |
| 27 |
|
| 28 |
As is, the package.use.mask patch that got shoved in gives _no_ |
| 29 |
indication that it's forcing a flag off for a pkg- leaves the user |
| 30 |
wondering wtf occured once they spot the flag is disabled. |
| 31 |
|
| 32 |
Point there is that arguing against it based on UI code is a |
| 33 |
non-arguement; either implementation (for portage at least) requires |
| 34 |
mangling portage's -vp code to indicate the forced disabling/enabling. |
| 35 |
|
| 36 |
> | *Full* implementation of use deps requires ability to flip on use |
| 37 |
> | flags as needed |
| 38 |
> |
| 39 |
> I implemented this a while back for Paludis and then chucked it. It |
| 40 |
> doesn't turn out nicely, mostly because of flags like build and |
| 41 |
> bootstrap. You'd end up with dumb cases like patch being built with |
| 42 |
> USE=build then USE=-build, and all kinds of hairy USE flags being |
| 43 |
> turned on. |
| 44 |
|
| 45 |
Alternative is not being able to resolve unixodbc/qt and sizable |
| 46 |
chunks of bootstrap'ing without resorting to telling the resolver to |
| 47 |
ignore cycles. |
| 48 |
|
| 49 |
This is part of why use deps aren't implemented in portage now; doing |
| 50 |
it *fully* requires a lot of bitchy internal tracking. You can ignore |
| 51 |
it, but resolution capabilities pay the cost. |
| 52 |
|
| 53 |
~harring |
Archives