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).


Attachment: pgpALdmcTUP2i.pgp
Description: PGP signature

Reply via email to