Re: Stretch stable and jessie testing - repositories listed
On Sat 11 Feb 2017 at 12:35:00 (+0000), GiaThnYgeia wrote:
> Jimmy Johnson:
> > On 02/10/2017 05:49 PM, David Wright wrote:
> >> On Fri 10 Feb 2017 at 16:00:13 (-0800), Jimmy Johnson wrote:
> >>> Hello,
> >>> Take a look at Synaptic Menu you can select a package and then go to
> >>> Package > Force Version, you can only force one package at a time
> >>> but, yes you can downgrade. I can down grade a couple hundred
> >>> packages without much problem, depends on the user.
> >>
> >> Oh, that's heartening! Does Synaptic use a different method
> >> from dpkg? The man page for the latter says (and the warnings
> >> look very pretty in red):
> >> Warning: At present dpkg does not do any dependency checking on
> >> downgrades and therefore will not warn you if the downgrade
> >> breaks the dependency of some other package. This can have seri‐
> >> ous side effects, downgrading essential system components can
> >> even make your whole system unusable. Use with care.
> >> Cheers,
> >> David.
> >
> > Hi David, Synaptic will not let you install a broken package. If you
> > are running sid/testing sometimes a package version will become obsolete
> > and need a change or a video driver version is not working and needs a
> > change, etc. If you're running in a GUI Synaptic is handy to have
> > installed. And yes, it's using "dpkg".
>
> One thing I have not been able to find in synaptic or elsewhere is a way
> to keep track of what has been installed and when. If you know where
> such a log habitates or can be created let me/us know.
I use aptitude rather than synaptic so you'll have to compensate for
that in what follows. There are three logs that I use.
The first is /var/log/aptitude.log which is rotated for only six
months. (I don't think I've changed any log rotation parameters.)
This only shows what you told aptitude itself to do, and only your
intentions, not the results (which might have been unsuccessful).
It also doesn't bother about versions, only package names.
The second was mentioned and is /var/log/apt/history.log which is
rotated for twelve months. This includes changes made with both
aptitude and apt-get, and it includes the previous and new version
numbers. That makes it messy to parse as you have to deal with
two levels of commas: ... pkga (ver1, ver2), pkgb (ver3, ver4), ...
The third is /var/log/apt/term.log (also twelve months) which logs
all the results of apt's work, but lacks any of your input. So you
need to look at the other logs to find out why apt did what it did.
It's very long-winded because it even includes the "progress bars".
> I understand it all relates to what depends on what and who is breaking
> whom. If it is a package that depends on other "stuff" but nothing
> depends on it you can install something from debian1 in its beta version
> and all else is fine. But if you go one version back of one little
> thing that 100 things depend on, you may get 90 things not working.
> This is my simplistic understanding. Out of my panic experimentation I
> have run into situations that it becomes a great puzzle of why the
> system is still working. Like creating a mess and breaking the system
> then reinstalling an earlier version of the distribution ON TOP of the
> mesh, same root and user names and passwords,
> then try to locate all the things that had been installed and upgraded
> that are not on the dpkg list and if not recovered they will remain
> unupdated. And it works! Like magic! I think all synaptic does is
> simplifying and remembering all the correct syntax of dpkg commands and
> executing them for you.
Well, I'd be interested to see the term.log from a session where
someone downgrades "a couple hundred packages without much problem"
as reported above. According to your experience, their statement of
"depends on the user" is untrue. Synaptic just sorts it all out for
you, though that's surprising in view of your last sentence.
I have little experience of downgrading, but have read plenty of
postings here about how difficult it can be. I would want a solid
backup system in place at the time, particularly if I were paying
bills with the work. In the past I always depended on having duplicate
systems and some bash scripts to get from the debian-installer to a
working system in short order.
Cheers,
David.
Reply to: