On Sunday 16 January 2005 13:33, foser wrote: > What you call tight I call well defined. It is no help to shift meanings > based on interpretations or situations, it only adds to the confusion.
Who exactly is confused, and what are they confused about? > What you forget is that you are a developer with a hundred times better > understanding of Gentoo than the general user. There isn't exactly a lot to understand about the concept of USE flags. There *is* a lot to understand about the impact of switching on a particular USE flag. It means that the user has to make a choice. The user has to decide whether to just switch it on and say "what the hell", or they have to look into what the consequences are for each package in turn. That second option is known as "due dilligence", and if you're building servers, it's part of the job. I happen to think that Gentoo w/ USE flags makes this easier than doing it with the alternatives, but that's a personal preference. I can see that non-technical desktop users might prefer the "what the hell" choice. I also think that Gentoo is really the wrong choice of Linux distribution for the "what the hell" group. Someone could (and should) build a Gentoo-based distro where the decisions are made for these users. But it's not the nature of Gentoo itself. And this is where I just don't understand your position on this issue, and a number of others. You're a Gentoo dev. You know how Gentoo works. But you always seem to be fighting against the way that Gentoo is. Not fighting for something, but always against. Take a leaf from the Tao, and embrace it instead. > Also the way you deal > with USE flags & setting them is probably not the way most people handle > them, otherwise we wouldn't have the different GUI USE flag tools. To be honest, I'm not familiar with what USE flag tools are available, what they are like to use, or their particular shortcomings. Unless these tools provide their own artificial USE flag groupings, I wonder if these tools actually make the USE flags seem more scary than they actually are? Maybe these tools are the real problem ;-) Nick et al have made some nice improvements in Portage 2.0.51 to the output of emerge -uav w.r.t. USE flags, and the output is well documented in the man pages. I wouldn't be surprised to find that the majority of these tools pre-date those improvements. > If > you can agree with that, then you can also see that the amount of USE > flags is a problem. I can't agree with that. What sort of proof is that? If you want to argue that the amount of USE flags are a problem for the *GUI USE flag editors*, that I understand and agree with. I'd like to see flags named as <category>/<flag>, to help these tools out. But that's a long way from saying that the amount of USE flags are a problem for the majority of end-users. *And* if the majority of users are happy, maybe we should follow your own advice, and "let the vocal minority yell at you for a while, that's gonna happen at one point or the other anyway," mmm? ;-) > And to be honest not only the amount, but also the > differing interpretations. A bit besides the point, but the last is > already obviously troublesome even for devs, because there's different > USE flags for the same things or USE flag with different interpretations > per pack. /me nods. I agree that we do have inconsistencies from time to time. That's why I think moving to a <category>/<flag> naming scheme would help. Provides a simple context to put the flag in some sort of perspective. > Anyway, the way you handle them is already indicative of where we are > heading, every update on a per package basis you have to deal with USE > flags. Not 'set once, run with it afterwards' anymore. Already in your > personal example dealing with USE flags has become a time consuming > repetitive task. And you are a dev even. Well, I don't find dealing with USE flags to be a time consuming task. I would be looking at the output from emerge -uav anyway, to see what packages are about to be installed and why. And I don't think that the 'fire and forget' approach you're after is practical or desirable. If users want to install software on their machines without thinking about the consequences, or understanding them, then maybe Gentoo isn't the right choice for them. They might be better off using an alternative, where those choices have already been made for them instead. This is exactly the area where a binary-pkg-based commercial distro based on Gentoo would be more suitable way forward. > In my opinion it shouldn't be added in the first place, if it's a > sensible feature it should be default. If it's not, well let the vocal > minority yell at you for a while, that's gonna happen at one point or > the other anyway. There's a tendency among devs to take the easy way out > and go with the socially acceptable solution instead of the best. If "the easy way out" == "optional support for a feature", then I'm with the easy way out camp every time. You're talking like tough decisions need to be made over this for the good of Mankind or something. And, to be honest, you're also talking like you're aware of what John's new USE flag does, and why some users want this behaviour. > > At the moment, USE flags are the only per-package mechanism available to > > users to indicate their choices. Maybe we need per-package FEATURES? > > That would seem a more appropriate place for John's symlink support? > > How would it be more appropriate & how would it be different at all ? Well, you've said that USE flags should only be for features supported by the package source code. So why not use FEATURES to allow users to switch on and off little things that the ebuilds do? And if we're going to do that, it has to be supported on a per-package basis. > Ridiculizing the opinions of others to prove your point, a bit of a > cheap shot. And not the first time it happened in this one reply. What do you find ridiculous about it? The fact that it's true? ;) Best regards, Stu -- Stuart Herbert [EMAIL PROTECTED] Gentoo Developer http://www.gentoo.org/ http://stu.gnqs.org/diary/ GnuPG key id# F9AFC57C available from http://pgp.mit.edu Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C -- -- [email protected] mailing list
