Hi Rui, On Tue, 2004-09-07 at 14:32, Rui Miguel Seabra wrote: > I never mentioned hiding, nor was that the intention. So how would you make such a failure stand out in an otherwise successful update? Example: Critical update was skipped because a dependency issue. Newbie: "Oh, it's just a warning as the program completed successfully." This is not more or less valid than the examples you give. > What multiple repos? Why do you suppose there have to be multiple repos > for this to happen? > > The latest problem of barfing due to obsolete packages happened recently > with xorg. You are correct that I make a bit of an assumption, but in stable distribution trees such conflicts should be seldom and if they do exist it's fine newbies start crying for help as there is obviously something wrong with the tree. > Huh? You're not understanding: > yum barfed because of obsolete packages. > if there was an unrelated security package, it wouldn't be applied > because yum barfed. Indeed the packages are unrelated. But... > As you can see, there is no X here: > [rms@roque ~]$ rpm -q util-linux --requires That might be so, but what makes you so sure hiding the xorg-x11 packages won't cause other updates to fail in the process? > I'm not demaning it to be solved, I wondered why something wsn't the > default and I don't see any answer with a sensible reason. Just > "NOTABUG" or "WONTFIX". "Not a bug" is quite different from "won't fix". > All I read were excuses. I can understand limited time, not bad and > arrogant statements, like expecting a newbie to be able to solve yum > dependency problems. The dependency problems are not in yum but in the tree(s). > > > > you write up the process for what has to occur and get EVERYONE to agree > Not perceive. Exists. A newbie user is placed with a "difficult" > challenge unecessarily, and important packages may not be upgraded due > to certain bugs in unrelated packages. Ok. But you perceive this to be a yum issue instead of a repo issue. And you still don't answer the essential part, namely give us a definition of how yum should behave in case of conflicts. Just skipping packages might cause unexpected side effects. > > but you have > > neither described a standard on how to handle it, nor have you got > > everyone to agree on your solution. > > I don't need to describe in detail what's taught on classes about > finding paths on mazes without getting lost on loops, do I? Cute. If it's so obvious to you you might want to come up with a patch so we can evaluate it. But iirc your first proposal was just to toggle a switch, which doesn't cut it. > You mark where you have been, so that if you find it again, you know > you've been there. > You mark obsolete "paths" until you find one that's already registered > (a loop). How would the entry point in that path (assuming a circular obsoletes situation) influence which package gets installed or removed? > Anyway, I'm not complaining my self. I just think this is a bad thing > for newbie users. For me? It's just a minute (or so) more. As pointed out these issues will hardly exist in single distribution repositories (they shouldn't). Leonard. -- mount -t life -o ro /dev/dna /genetic/research
