[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [apt] Fails to upgrade form Wheezy to jessie with apt+dpkg first



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


Reply to: