On Thu, Mar 04, 2010 at 06:07:17PM -0600, Dale wrote: > chrome://messenger/locale/messengercompose/composeMsgs.properties: > > On 03/04/10 12:53, Ben de Groot wrote: > >> Exactly. The last time I owned a printer is over 5 years ago. So I don't > >> think cups warrants to be in the standard desktop profile. > >> > >> Cheers, > > > > I print almost daily, but I'm not sure if printers are commonplace > > enough for cups to be a default. Some users may expect it though. > > > > As for the circular deps, it would seem more logical to fix the > > problem at the source, rather than to cover it up for one subset of > > users. > > > > > I can't think of anyone that doesn't have a printer. All my friends and > family that has a computer has a printer. Heck, I had a printer hooked > up to my old Vic-20 for goodness sake. That was over 20 years ago.
A sampling size of one is of course representive of the whole. The vast majority of gentoo deployments I deal in, cups is bloat- my personal laptop, sure, that's a different story. That's well under a tenth of my installs however. The point there is that one size doesn't fit all- we have inheritance in the profiles for a reason. Shift cups out of the base and into desktop specific profiles. That one shouldn't be a point of debate. > He wants to remove the USE flag so that it hides the fact it is not > really fixed. If a person does their install as they should, the > problem will be right there for them to deal with. Of course, the user > will the one getting pointed at since they added the flag. Two scenarios. 1) flag is left on by default. emerge pukes at them about the use cycle, user has to go googling and try to figure out the way around this (with the end result being "flip the flag off, merge stuff, flip it back on, rebuild the affected pkgs" 2) flag is left off by default. things emerge fine, but user finds they don't have printing. So... they google it, find out that they need to turn a use flag on and then do an emerge -N. Of the two *viable* scenarios, #2 is frankly the one that's going to be less of a pita to users- the folk who need cups on a desktop have a clear and simple path to getting cups, versus #1 which requires the user to understand dependency cycles induced by use state. One thing to note- for #1, the user is going to have to do the same steps as #2, they're just going to hit a terse failure instead of finding that when they go to print, they need to rebuild w/ cups support on. #2 contains the issues/breakage a helluva lot more than #1 does. > It takes the problem off the people that created it and adds it to > the user. That is not how it should be fixed. Lay off pointing fingers. Cycles exist and are rather hard to fix- if in doubt I strongly suggest you do some research into how stages are built (and the existance of the build use flag). The problem is the interdependence in the raw src itself, not ebuild devs. The use state induced hard dependency cycle issue has been known for a long while- the solution to this requires the resolver being able to break the cycle via building the pkg multiple times with the use state varied to break cycles (as far as I know, none of the PMs do this although pkgcore could at one point). Modifying the resolver to do that sort of cycle breaking is rather tricky- work should be done towards it, but it's not the sort of thing that's going to be implemented today, and stabled tomorrow. Basically, punt the flag if you don't want users to hit a cycle on fresh installs- it's the only option that exists *now* (and those screaming should focus their efforts on implementing the use cycle breaking I mentioned above). ~harring
pgpALdmcTUP2i.pgp
Description: PGP signature
