Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Debian dpkg (http://www.linux-archive.org/debian-dpkg/)
-   -   dep-trace v. tsort (dpkg, source, bsd, reason) (http://www.linux-archive.org/debian-dpkg/641692-dep-trace-v-tsort-dpkg-source-bsd-reason.html)

"John D. Hendrickson and Sara Darnell" 03-06-2012 09:59 PM

dep-trace v. tsort (dpkg, source, bsd, reason)
 
Hi. I'd like to make sure i mentioned this. Bug yes, not needing fix today, a look ahead.

SUBJECT: lack of dependency sorting; untangling dependency in dpkg lists
OBJECT: http://www.sourceforge.net/projects/dep-trace (see below)

Debian [easily] installs 850 pkgs at a time: each having dependencies. Dependencies are resolved to
to build the list: BUT the order to install / configure is un-ordered. If the list were optionally
dependency sorted (non-mandatory) success is more likely. $cat list | dep-trce # (sort it)


(If a stop occurs in the long process this can leave problems. Some postinst sh incorrectly assume
order.)


What of source package builds? see below, it does have some discrete usefulness.

Example. FreeBSD and Apple use tsort(1) during "portage" (checks 1st depends list, downloads all,
check new lists. Then chain compiles). How is tsort(1) used? Tsort yeilds the order to compile
in. When? Port A says it needs B and C compiled first. But B and C also have requirements not
known until fetched ! A can't know, doesn't say. Thus tsort is used AFTER it downloads and has all
sublists.


OOPS! topological sorting isn't right all the time. (i.e., "loop detected - bailing out ...", or
"libxxx ... compiling ... failed ... lib yyy not yet installed") (what a pain!) Why? tsort does
vector graphics ordering (arrows pointing to objectives, see wikipedia) and compilers simply can't
do that. Compilation does requires order.


/bin/dep-trace is a small speedy sorter, operates like sort(1), using regular math rules rather than
"value added" ones. It has no dependencies itself. It may have other uses in ordering lists.



Thanks all, and I hope it's not a bother having this in debian-dpkg list once,


John


Further details...


#### misc note

make(1) orders compiling (dependency) yes, but make language and it's stat file checking isn't
conducive to ports/pkg install as being done today (see below for more)



### complicated ### Debian builds ###


Source packages. Build may fail, or possibly have side-effects, if compiled in the wrong order.

And there are THREE plausible for using sorted depends lists.

Weakest first: (please correct if I'm wrong). Same as install of dpkg list: un-ordered. If dpkg
gets a source pkg LIST it may try the LIST in the wrong order (it guesses you are building one .dsc
per say).


A second circumstance is if Build-Depends:[list] If Build-Depends list within pkg X list is not
well ordered (or aged) or not processed in same order. (or just plain mistakes)


The third: discrete circumstance. If build X says package A B C must be pre-built: but due to
changes package B it must be built before A. (restating that: while dpkg-checkbuilddeps(1) may
prevent B from being built, dpkg-buildpackage(1) won't double back to do A after B. Why? This is
because package X doesn't know the dependency structure of A or B nor does it sort them - not until
Build-Depends is edited manually - dot your t's cross your eyes, is ordered thus FIXED :)


(comparison, remembering BSD/apple above - if you [use an ability] to chain download and compile
like bsd ports (pre-fetched or not) do you can't assume to know the depends of A and B (maybe
upstream changed?) Developer may perfectly not care if attempting many ports if they build to begin
with is a nice start right?)


Summary.

dpkg-buildpackage acts like make(1) in that it checks for file existence, all or none (which is
required and good). However, like make dbp isn't going to double back: you won't know what the
right dep order is until it fails and you manually trace the A B C order somehow to find X doesn't
know B comes before A.


Uses.

dep-trace is not amazing as to upgrade of .dsc: but rethinking "the usual confusion involved" it
does. Also if there is confusion caused by deps it can show why (if X's idea of dep lists in A and
B is out of date).



--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F5696BC.6050409@cox.net">http://lists.debian.org/4F5696BC.6050409@cox.net

Raphael Hertzog 03-07-2012 06:46 AM

dep-trace v. tsort (dpkg, source, bsd, reason)
 
On Tue, 06 Mar 2012, John D. Hendrickson and Sara Darnell wrote:
> Debian [easily] installs 850 pkgs at a time: each having
> dependencies. Dependencies are resolved to to build the list: BUT
> the order to install / configure is un-ordered.

There is an order for the configuration since we ensure that dependencies
are satisfied during the postinst configure (except loops). If it fails
despite this, then it's a bug in the dependencies (or something entirely
unrelated).

So I fail to see your point really.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120307074658.GH10999@rivendell.home.ouaza.com">h ttp://lists.debian.org/20120307074658.GH10999@rivendell.home.ouaza.com

"John D. Hendrickson and Sara Darnell" 03-07-2012 04:51 PM

dep-trace v. tsort (dpkg, source, bsd, reason)
 
Thanks ! I'm sure someone "is aware" :) Was not sure it posted.

Correct and yes your right, but not "optimal". Let's say apt selected this depends list:

A
B C
D

All satisfied as a list to install, yes. Should work, the book says.

But if installed in order "C B D A" it may cause headaches (see below).

If optionally applied in order "A B C D", sorted by deps, success is more likely.

If ever you need "low level" depends sorter you'll know one exists, have one to look at or compare to.

Have a good day thanks much for the question,

John


#### examples #####

#0 I see many avoid using Pre-Depends, as it's "strict", when they could
and the rules suggest not to use Pre-Depends without permission ?

#1 if C is alpha and made some assumption about B already existing
if running system / user tries using C before B is ready

#2 if install stops (ie, Ctrl-C) and system breaks until corrected
(ex: C is an admin util, B is perl, to run C to get work done
you need both B C installed, but your power got shut off after
400 pkgs, leaving you with C but not B and maybe both broken)

#3 once a break happens there "are no rules" per say and both may have
difficulties installing after that

These kinds of things can be frustrating and time consuming.
The longer the install list, the more chance of mistakes or partial install.

##### in a 90's release, "buzz", install guide called lack of order "a bit loopy"


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F57A006.4090106@cox.net">http://lists.debian.org/4F57A006.4090106@cox.net

Goswin von Brederlow 03-08-2012 04:28 AM

dep-trace v. tsort (dpkg, source, bsd, reason)
 
"John D. Hendrickson and Sara Darnell" <johnandsara2@cox.net> writes:

> Thanks ! I'm sure someone "is aware" :) Was not sure it posted.
>
> Correct and yes your right, but not "optimal". Let's say apt selected this depends list:
>
> A
> B C
> D
>
> All satisfied as a list to install, yes. Should work, the book says.
>
> But if installed in order "C B D A" it may cause headaches (see below).

If it causes headaches then the packages are bugy because they did not
set the right dependencies. And if they did not set the right
dependencies no sorting tool will be able to sort them magically right.
Apt and dpkg already use all the dependency informations to sort
packages correctly. The order they find is not unique but is no better
or worse than any other order that doesn't break the dependency
restrictions.

> If optionally applied in order "A B C D", sorted by deps, success is more likely.

The dependencies of packages define a partial order and any order that
does not violate that partial order has to succeed. Otherwise the
packages dependencies are buggy.

And since people don't always install "A B C D" as set but frequently
just update a subset it is pretty much garantied that over time and many
many users any order of that set that is allowed will be tried. So this
really is a must work. There is no "is more likely", it has to work in
any order.

> ##### in a 90's release, "buzz", install guide called lack of order "a bit loopy"

Dpkg and its frontends have come a long way sinze buzz.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87r4x364q9.fsf@frosties.localnet">http://lists.debian.org/87r4x364q9.fsf@frosties.localnet

Jonathan Nieder 03-08-2012 06:12 AM

dep-trace v. tsort (dpkg, source, bsd, reason)
 
Goswin von Brederlow wrote:

> If it causes headaches then the packages are bugy because they did not
> set the right dependencies.

To avoid too much noise: John has been performing upgrades that skip
many major Debian releases and expecting them to work for some reason.
The tsort hack is not enough to make that work (and has nothing to do
with dpkg), but hopefully this gives some context for why he is doing
it.

Cheers,
Jonathan


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120308071243.GB2181@burratino">http://lists.debian.org/20120308071243.GB2181@burratino

Chris Jones 03-08-2012 10:25 AM

dep-trace v. tsort (dpkg, source, bsd, reason)
 
> So I fail to see your point really.

Whoa there, tiger..

How did I end up on this thread? Is there a problem with one of the mp packages I maintain? (NB: for some value of maintain that consists mostly of putting my email on some packages on account of having authored them, then promptly forgetting about them).

I missed whatever preceded your reply, so i'm at a bit of a loss to make sense of this, especially how it'd involve Debian, or anything in the subject for that matter.. I don't remember my stuff having any serious dependencies, but this is macports of course, they quite possibly picked up x11, gtk, and 2 different versions of python with no effort on my part.. I kid! (mostly..)

Anyhow, if you need me to fix one of my packages please bring me up to speed and i will do so, or will at least kick it to someone who cares a bit more than I am likely to at the moment.

(also occurs to me this is flat out missent, in which case just remove me please, thanks..)


Cheers,

--
Chris



On Tue, 06 Mar 2012, John D. Hendrickson and Sara Darnell wrote:
> Debian [easily] installs 850 pkgs at a time: each having
> dependencies. Dependencies are resolved to to build the list: BUT
> the order to install / configure is un-ordered.

There is an order for the configuration since we ensure that dependencies
are satisfied during the postinst configure (except loops). If it fails
despite this, then it's a bug in the dependencies (or something entirely
unrelated).



Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: BA73CF83-67D4-48E4-A923-4AA005423143@gmail.com">http://lists.debian.org/BA73CF83-67D4-48E4-A923-4AA005423143@gmail.com

"John D. Hendrickson and Sara Darnell" 03-09-2012 01:50 PM

dep-trace v. tsort (dpkg, source, bsd, reason)
 
Your right, that's a rule, it should work flawless when orderless.

Yes, if all pre-depends and depends are proper, consistent, complete, up to date. Some are "loose".
(ie, sed v. tar : tag lib6 differently in squeeze) though.


One still has to install base before optional. If that occurs in one apt tag install run I can't
see an orderless argument. (ie, during "challenging" upgrade)


It wastes time and frustrate newbies if anything goes wrong. As optional code can system(dep-trace)
and use list if returned. As optional.


DEP-TRACE as a small libc6 /bin that can be used or set aside any time. It prints ordered deps
quicker than a high level app can import a table. Isn't that fun in itself? :)


Have a splendid day all,

John

Goswin von Brederlow wrote:

"John D. Hendrickson and Sara Darnell" <johnandsara2@cox.net> writes:

<snip>


But if installed in order "C B D A" it may cause headaches (see below).

>> If optionally applied in order "A B C D", sorted by deps, success is more likely.

And since people don't always install "A B C D" as set but frequently
just update a subset it is pretty much garantied that over time and many
many users any order of that set that is allowed will be tried. So this
really is a must work. There is no "is more likely", it has to work in
any order.


##### in a 90's release, "buzz", install guide called lack of order "a bit loopy"


Dpkg and its frontends have come a long way sinze buzz.

MfG
Goswin




--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F5A18C9.1050509@cox.net">http://lists.debian.org/4F5A18C9.1050509@cox.net


All times are GMT. The time now is 07:32 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.