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

Re: dpkg BUG install order problem & suggestion to add...

debian-dpkg@lists.debian.orgJohn D. Hendrickson and Sara Darnell wrote:

(to jonathan - repost - I did reply incorrectly)

Jonathan Nieder wrote:

John D. Hendrickson and Sara Darnell wrote:

I've always had problems especially during upgrade (last was sarge
to sqeeze) and wished to help.

Thanks for the offer of help.  There are always problems with upgrades
"skipping a few releases" like this, since package maintainers do not
tend to think about or test upgrade paths other than Debian N ->
N+1.  In particular, often there will be a package or two that assumes
packages have already been upgraded to the version from the previous
release without declaring specific dependencies in that vein.

So the usual advice is to upgrade one release at a time:

 sarge ->
  etch ->
  lenny ->

You are right. The extra work takes as much time as saved I presume :) But good advice.

While the problems is worst when upgrading - it comes up now and then when doing any install change that tags a large number of packages.

Of course if there is some simple way to allow shortcuts (e.g., some
tool to perform multiple upgrades after a person types a single
command?) then that could be very interesting.

What order? Dependancy order. tsort. It can be done I did it. You can build it 1x for all packages then check against it. (there are side-track details about when and why do rebuild the list more than 1x)

For clarity, could you give an example of problems you ran into?
I.e., what command did you run, and what bad behavior resulted?

Sure. debian.org documentation release-notes (upgrading). Says to expect glitches.

# apt-get upgrade
    begins reasonable - some pkgs fail so...
# apt-get -f install
    sometimes manual fixing is necessary
    usu. just force file overwrite
# dpkg --configure --pending
# apt-get upgrade

--> Here is where we see large install lists develop that want to install out of dependency order, very different from origional list. Happens after upgrades need to recalculate, the pkg "grading", what the list to install is, the etc.

Again I'd mentioned it's likely more a problem during upgrade but not totally upgrade specific.

My suggestion is NOT to replace what is there but to add a method.
The method checks the final install decisions.  It easily shows what
order they should be done in AND whether they go out of bounds.

Perhaps you are looking into changing the upgrade order to avoid
running into temporary conflicts and other dependency problems?  If so,
yes, that sounds very welcome, though it probably has more to do with
higher-level tools like apt, aptitude, and cupt than dpkg (and alas,
it wouldn't be enough to address the problem described above).

I have a working example of what to do that mostly uses existing
unix tools.

Well, what are you waiting for? :)

I don't wanna just dump code only I can read :)

(I can send the code but it's a makefile (to keep table build parts up to date), uses mostly awk, etc, and mostly table building, some simple lookup scripts like rdeps, etc (in awk))

*** So what I'm saying is installer(s) sometimes choose to try to install higher
*** dependencies before lower dependencies, again the order.

upgrade also limits the number of items attempted (see above, apt-get upgrade v. dist-upgrade). However packages which depend on allot (ie, gnome) end up in the "limited list" and the limited list it seems grows.

The thought is this. Take all dependencies and sort them in one list. Really once have to do it 1x.

THEN. Whenever (install, upgrade, anytime) has a list it wishes to install / remove it can order that list before attempting by the dependency sorted list. Since the deps are already sorted ordering the packages doesn't even require sorting but just list-list order.

I tried tsorting all pkgs it works (ie, libc6 is low on list, zope-tinytables high).

The "/var/lib/available" list itself could be in tsorted order. I don't see the order in it myself.

YES, there are details. Build the list once or every time (fast pc only, 20min. takes a while on a pentium). There is a detail about ORs (which I ignore since what installer next chooses as "a good grade" changes - meanining you MIGHT have tried to install both ORs when your done: true story! )

Ok. Hope you understood that enough. If you like I can send example script or post it somewhere.

(prepare data) | tsort | tac > ordered list

when looking up, given any pkg name, you get a depth into the list (so ordering any given list is a cinch)

Thanks for writing, and good luck.

Well thank you!

    John Hendrickson

Once again I'll say I also love these pkg managers. I realize there is a need for what they do even if my method is added. Even if "perfect dependency order" happens for a particular install list or is even automatic: there is still the issues of deciding which to pick for the user which debian's pkgs suites are simply tops at doing !

have fun :)

	John Hendrickson

Reply to: