fedora-list-request@redhat.com wrote:
Message: 10 Date: Fri, 07 Nov 2008 12:01:41 -0430 From: "Patrick O'Callaghan" pocallaghan@gmail.com Subject: Re: fedora-list Digest, Vol 57, Issue 47 Dependency Champion To: fedora-list@redhat.com Message-ID: 1226075501.3141.3.camel@bree.homelinux.com Content-Type: text/plain
On Fri, 2008-11-07 at 16:48 +0100, DB wrote:
Having been bitten several times by Yum's ideas of "what depends on what", I agree with Henk. If I have 2 (as far as I can see & understand) independent, stand-aloneable programs eg Cups & Firefox, it ought to be possible for me to remove either without automatically taking out the other - no, I've never even thought of the work that must go into something like that!!!!
As Michael pointed out, this has absolutely nothing to do with Yum. The packages were specified with certain dependencies and Yum is simply following the spec. I'm sure you're not suggesting that Yum should examine the packages and determine if X *really* depends on Y ... BTW, if possible don't use Yahoo to reply. Its idea of message threading (not to mention quoting) seems to be completely broken. poc
Hi POC,
OK... if Yum is a "dumb" servant, then the definers of dependencies maybe should look into how things are listed - IM*V*HO. Surely something **optional* *that I install after the initial set-up cannot become a dependency of something which is/was supposed to work without the (unrelated) optional bit???? Or as Yumex so kindly lists all wot it's going to kill off, could there not be a way of deselecting those elements that are "obviously" wrong??????
(Thanks for the hint on the reply -- I use Thunderbird as my mail manager & didn't do a very good job on cutting out the bits of the Digest I didn't want to quote - mea maxima culpa, not Yahoo's fault this time!)
TTFN
Dave
DB wrote:
Surely something **optional* *that I install after the initial set-up cannot become a dependency of something which is/was supposed to work without the (unrelated) optional bit????
You are correct, that can not happen.
Or as Yumex so kindly lists all wot it's going to kill off, could there not be a way of deselecting those elements that are "obviously" wrong??????
If you instruct the tool to remove a package, it does not remove other packages randomly or haphazardly. You may not understand the package relationships, but that does not make them wrong.
On Fri, 07 Nov 2008 13:31:05 -0800, Gordon Messmer wrote: [...]
If you instruct the tool to remove a package, it does not remove other packages randomly or haphazardly. You may not understand the package relationships, but that does not make them wrong.
Nobody has suggested that any mental state makes them wrong. What does make them wrong, dead wrong, is a fundamental principle of Unix -- every tool should do *one* job, and do it well.
You'll find that near the front of any book introducing people to linux. (Remember books? You probably still have some. They're very good for things like history, which doesn't change much.)
In most such books, you'll also find an assurance that that principle is what makes *ix the triumph that it is, and all the works of Redmond the creeping disasters that they are.
Beartooth wrote:
On Fri, 07 Nov 2008 13:31:05 -0800, Gordon Messmer wrote: [...]
If you instruct the tool to remove a package, it does not remove other packages randomly or haphazardly. You may not understand the package relationships, but that does not make them wrong.
Nobody has suggested that any mental state makes them wrong. What does make them wrong, dead wrong, is a fundamental principle of Unix -- every tool should do *one* job, and do it well.
Now you're arguing philosophy against fact, where "wrong" doesn't mean "incorrect" but "not the way I think it should be done". If you're convinced of your philosophy, you're free to contribute a better solution.
Pango does one job, and does it well. Pango does text layout. The intention behind pango is that it can lay out any text, including Thai. The pango developers reused an existing library for Thai layout rather than writing their own. Pango is a reusable component that builds on other reusable components; another popular development philosophy.
You'll find that near the front of any book introducing people to linux. (Remember books? You probably still have some. They're very good for things like history, which doesn't change much.)
Your condescending attitude will convince no one that you are right or reasonable, nor will it go far toward creating a community of people who are willing to provide you with advice or assistance in the future. Consider the ideal conduct of the community that you would like to be a part of, and act to create it.
In most such books, you'll also find an assurance that that principle is what makes *ix the triumph that it is, and all the works of Redmond the creeping disasters that they are.
Such assurances remain speculation.
I think our problem here is that the human mind has in it the concept of "soft dependencies." That is, "This program can use that feature if it's installed, or else carry on just fine without it." So removing a feature shouldn't force removal of a program that could work without the feature.
But that means that every program must be smart about what it can and can't do at run time. Being myself a programmer, I understand that it is a lot of work to implement this, especially for large programs that could potentially have many optional functions. So I can't really fault programmers for taking the lazy path and saying, "My program *can* do printing, so you must have CUPS installed to install my program, whether you intend to ever print or not."
It would be ideal if this were not the case, but I don't see a lot of programmers willing to put in the extra effort. In the meantime, we're stuck with, "I can't remove wireless-tools (from my machine with no wireless hardware whatsoever) unless I can live without system-config-users." This is where average users get confused and frustrated, because they understandably don't see any connection at all.
-
Alan Evans -
Beartooth -
DB -
Gordon Messmer