On Sat, Feb 07, 2015 at 05:32:18PM +0100, Holger Levsen wrote: > On Samstag, 7. Februar 2015, David Kalnischkies wrote: > > > $ apt-get -y install dpkg apt > > > [... tons of debug output ...] > > > > Well, as the one who asked for all this output to be generated, let me > > say that I am happy about it as it means that the following is curtsy of > > just reading and skipping over these lines rather than taking hours to > > get this reproduced. Its all a matter of knowing what they actually > > mean of course. Someday I should give a course… > > :) > > As someone who thinks the logs are too big and uncomprehensible now (iceweasel > is not scrolling these huge logs nicely anymore), I wonder if there's an > option to write these extended logs into a file, which can be downloaded > seperatly? We could run each apt-get install/upgrade/dist-upgrade with --assume-no instead of -y first and redirect all its output into a file. That at least gives us the resolver stuff we were looking at here. (beware, apt-get will exit non-zero with this option) The installation order on the other hand… Maybe --simulate instead of --assume-no, but that adds a bunch of output which is only vaguely useful (and sometimes even "wrong"… the simulation will claim the installation order is broken and fail while in a real run with dpkg it will work anyway [in 99,9% of the cases at least]). Maybe just drop this debug option again instead. > Because, I have already thought about removing this debug output again, > because it makes the logs unreadable to most of us. Simple solution: Learn to read it. ;P After all, what is the point of packaging 30.000 things if you can't install them given it hardly scales having a single person looking… but well, to serious of a talk after a nifty remark with a smiley. > Or: if a job fails, run it again with debug output enabled, and save that > second run output in a file which can be downloaded seperatly... Well, I was asking in the initial bugreport for how easy/hard it is to let jenkins spit out additional files. If that is really easy (as said, I have no idea) we could just add a bunch of files (mostly dpkg/status files from various steps) and be done. Its simple to feed them to apt and would give anyone interested the option to re-create the problem relatively easy. Would be even preferable over any debug option in the end as in the (totally unlikely of course) event of an apt bug you can test directly. Bad idea usually, but I am in a good mood now so lets say it anyway: Throw me in the general direction of some documentation detailing this and I hope I can come up with another patch for the job. > > So, the solution to this is not in apt, nor is it an apt problem per-se. > > If you decide that this "upgrade first" scenario isn't of interest this > > is a non-issue. Everyone should just do a "apt-get dist-upgrade" and be > > done. > > That's neither what the release note say nor what people do. Since years I > alwys do "upgrade" first and then "dist-upgrade"... Right, I am still in the squeeze mindset which had this only as a sidenote (it was the first release with me on the frontline, which is also why I am always referring to the udev+dpkg+kde bundle in it). Doesn't really matter all that much, but doesn't hurt either. That was really more about me saying that in the current state of affairs, there isn't much point in doing a "apt-get install apt dpkg" first if it does the same as "apt-get dist-upgrade" (more or less at least). > > P.S.: 'install' and 'dist-upgrade' have a very different approach to > > solving, so I am not very surprised that 'install' fails to do it and > > I doubt that problems seen in the bottom-up approach can be seen in > > a dist-upgrade - mostly as the cage-fight scores will be different. > > Do you think it would be worthwhile to have another set of tests, where we do > "install" instead of "dist-upgrade"? jenkins ressources are cheap, finding > errors by chance through humans is expensive ;-) I am not sure what you are suggesting here? Maybe I was just suggesting the wrong thing. "very different" was a bit much I guess. In reality dist-upgrade is an "install ^.*$/installed" (still a lie, but its at least very close to the truth), so all I was trying to say here is that what we see here is not happening with dist-upgrade as it can by definition not miss to schedule a package for upgrade (upgrade is similar as it does the same, but doesn't allow new/remove actions). But let me try to answer that more general: I am not sure what we test with jenkins here after all. Don't get me wrong, they are great, but I am not sure what the goal is. The solution apt calculates is potentially different for everyone as everyone has a different set of packages installed, so ideally if we wanted to test apt upgrades we would have hundreds/thousands of status files of wheezy and let apt upgrade them all to jessie. That is pointless without automatic validation through regarding which packages should be removed or not. And it would probably kill jenkins as that would literally take ages to finish if we really perform it, so if we wanted that (and in the longrun I do) we need to drop the actual installation in favor of just solution sanity checking. [jftr: I want this not so much for upgrade testing per-se, but for resolver testing as its currently hard to reason about changes to the internal resolver as well as about stuff like aptitude or even external resolvers like aspcud]. If, on the other hand we want to see if the upgrade can actually be performed, we might want to analyse popcon in terms of maybe the 5 "most common" systems and do complete runs for them. If you want to stress-test apt/dpkg, install ALL (or very close to that) packages and then try an upgrade. That is far away from a "real" system, but it tests all replaces/breaks/conflicts … The thing with all these tests is that someone has to sit down and actually look at them (or design a system which looks at them). If apt wouldn't have errored out here for example, would have anyone noticed that the initial install command deals with most of the upgrade already? Best regards David Kalnischkies
Attachment:
signature.asc
Description: Digital signature