On Monday 18 May 2009 21:20:10 Ciaran McCreesh wrote: > On Mon, 18 May 2009 21:08:25 +0200 > > Patrick Lauer <patr...@gentoo.org> wrote: > > In terms of the on-disk result it's invariant, the result is what > > you'd expect. There are intermediate stages that are "inconsistent" / > > "unclean", but as these are known and temporary they are an > > acceptable solution. > > No, they're temporary except when things go wrong, at which point > there's no indication that they'll be fixed. > When things go wrong they go wrong. Indeed. At the moment I can't think of an obvious failure mode, so I guess I'll have to wait for you to refresh my memory. Until then I'll just be happy that KDE, poppler, e2fsprogs and a few other apps refused to fail and saved me lots of time and trouble (and some failure modes that are really frustrating) by just magically upgrading in the right sequence, avoiding error-prone user interaction (e2fsprogs had one funny bug that a few hundred users found) and allowing me to be a lazy cat.
> > > It's unrealistic to assume that depclean's going to be accurate at > > > every given moment, especially given Portage's massively > > > overoptimistic treatment of slots. It's also a very bad idea to > > > remove packages without the user explicitly giving permission to do > > > so. > > > > Which either means that the deps are wrong/incomplete or that portage > > has algorithmic flaws which should be corrected. > > I'd expect you to at least point to the relevant bugs and not just > > state some emotional mumbo-jumbo. > Look at the new slot deps in EAPI 3. So the deps were not precise enough, and now we improve that. Which means that portage will only get more precise in the future. Awesome! > No, broke. What he did was in direct violation of PMS and in direct > violation of assumptions made by many packages. So PMS did once again not reflect reality, and there were some buggy packages. Maybe we should spend more time on making PMS a standard that documents current and past behavior instead of omitting things (mtime, bash 3.1) or keeping it ambiguous so that two implementations can be compliant while delivering incompatible results? And then ... well ... bugs are there to be fixed. > > > * work by explaining the reason for the blocker, rather than sort-of > > > stating the expected resolution. > > > > That's dumb ;) (Sorry, emotional statement) > > I mean, it does not help to solve the issue and requires user > > interaction where an automated solution has been working reliably for > > quite some time. > > Uhm. Knowing the reason for the block lets the package manager solve > the problem in the most intelligent available way. Merely being sort-of > told the expected resolution does not. You're contradicting yourself there - until now you only mentioned user- visible messages, which now suddenly become hints for the package manager. Don't try to confuse issues like that. Now I do wonder what you can "explain" about a block - "some files collide" ? How does that help the package manager decide what to do? What can it do, except unmerging one package or refusing to merge another one? How does that differ from the portage solution to the blocker situation? > Automated resolution is not always possible Indeed, in such cases you can let the package manager abort > or a good idea. Again a subjective thing. This bacon here, buying that was a good idea. I should give you some, it's totally awesome! > Also, > having more information available for the user and being able to > suggest an automated resolution are not in the least bit contradictory. ... which means that we can let the package manager handle all the "obvious" cases and try to give the user more information in the rare cases where it cannot find a valid solution on its own. Cool. > > > * be based around tree requirements, not some side effects of some > > > code someone happened to write without considering the implications. > > > > What is a tree requirement? (Nice buzzword btw) > > A tree requirement is one that comes about as a result of studying what > ebuilds do now and what they'd like to do in the future, rather than > one that comes around based upon what someone happens to code. I am confused. I did not think that ebuilds have desires, so I have no idea what they'd like to do in the future. And it does in no way tell me what a tree requirement is (unless you mean happy photons, which are emitted by free- range ebuilds when you try to source them in the kitchen) Incidentally most of our ebuilds are based upon what someone happened to code. Personally I think that many upstream devs didn't have a great plan (or at least they didn't like to express it in the code ;) ) and still we have an ebuild based upon their coding, uhm, accidents. But we adapt to it, and the result is quite impressive. Somewhere a while ago I read a funny idea - the more rules a contract needs the less trust there is. If you trust someone you agree, shake hands, deal complete. Only if there is not enough trust do you need lawyers, notaries and politicians. A long time ago we used to be able to just agree how things work ... now we have a ton of legalese (PMS) and things get more confusing every day. I don't think this evolution towards self-sustaining bureaucracy and incessant lawyering is useful for the end users. > > And as many devs and users benefit quite a lot from the portage > > solution, which zmedico did not dream up without thinking about the > > impact on users, I find it very rude and condescending of you to > > disrespect the solution without offering an alternative. > > ...except for the things that it broke, which necessitated shoving !! > blocks in at the last minute. And I'll remind you that there were > discussions about a proper blocker solution before Zac went and did his > thing, bikeshedding and circular reasoning in large amounts, stalling any progress for a long time ... until someone provided a working implementation that solved a large enough amount of issues to gain the support of the majority of devs (and big cheers from so many users!). (If it had been as bad as you suggest council would have banninated it within the shortest amount of time...) > and the overwhelming view a minority view, but let's not get distracted by such subjective matters. > was that a solution based around the > things I've been discussing was what was wanted. So your point of view is that the solution proposed by you is the best. Intriguing. Circular, subjective, but not really convincing. > > As you seem to understand the problem domain I'd expect a coherent > > unambiguous proposal instead of vague accusations and emotional terms > > that do not help in any way to improve the situation. > > See the discussions we had back when the only kind of blocker was a > hard, single ! block. I'm not aware of a complete proposal in those discussions. Mind giving me a link to that one so I don't have to spend lots of time trying to track it down in the almost 70000 mails archived by gmane?
