Date: Mon, 21 Apr 2003 02:51:56 +0300 From: Maxim Sobolev <sobomax@portaone.com> To: Kris Kennaway <kris@obsecurity.org> Cc: Sergey Matveychuk <sem@ciam.ru> Subject: Re: [kris@freebsd.org: cvs commit: ports/Mk bsd.port.mk] Message-ID: <20030420235156.GA47321@vega.vega.com> In-Reply-To: <20030420215832.GC78660@rot13.obsecurity.org> References: <000b01c3074d$d189c890$0a2da8c0@sem> <20030420215832.GC78660@rot13.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Apr 20, 2003 at 02:58:32PM -0700, Kris Kennaway wrote: > On Sun, Apr 20, 2003 at 07:02:09PM +0400, Sergey Matveychuk wrote: > > Kris Kennaway wrote: > > > The 'deinstall' improvement is particularly interesting. It should > > > not be a huge amount of work to make a decent 'make upgrade' and 'make > > > recursive-upgrade' target that does a portupgrade-like sequence of > > > backup/deinstall/build/install on the current port (and its > > > dependencies). I'd love it if someone felt like working on this! > > > > I'v had this idea. And I'll plan to work for it within next week. > > > > Has somebody comments or suggestion for it? > > I gave it a try, but the recursive-upgrade target is not so easy. I > wrote a modified ALL-DEPENDS-LIST that recurses into children and > sorts their dependencies in topological order, but it is very slow > (~10 minutes for gnome2). Maybe I am missing something, but what's wrong with make package-depends target? It does this in a reasonable time even for packages with very long dependency lists. I think that it should be fairly easy to make it printing not only raw list, but to sort it in a dependency order by propagating some number into the recursion process, which will be printed along with the name of dependency and will be increased on each recursion level. Then you will be able to tell that packages with the same numbers doesn't depend on each other, wile those with greater numbers are dependencies for those with smaller ones - see the graph below: P1 1 |\ | \ P2 P3 2 | |\ | | \ P4 P5 P6 3 /|\ \ / | \ \ P7 P8 P9 P10 4 | | P11 5 By running such modified package-depends target in P1, you will get after sorting: P2 2 P3 2 P4 3 P5 3 P6 3 P7 4 P8 4 P9 4 P10 4 P11 5 Which will give you perfectly valid order of upgrade process (from greater to smaller), and allso optionally can be used to do parallel dependencies building, that would be useful on N-way machines. You could ask, what if for example P11 also happens to depend on say P4, but since information about already visited dependencies only propagates downwards, you will visit P4 node twice. Therefore, P4 will be printed two times, once on recursion level 3 and once on recursion level 6, it should not be that hard to select only one with highest recursion index (currently it just gets filtered out by performing sort -u on received list of dependencies). > Instead the way to do this would be to > parse the dependencies listed in INDEX, which is what portupgrade does > (like portupgrade, this would assume you have an up-to-date INDEX). I think you are mistaken here. portupgrade uses INDEX only in the case when it has trouble finding root of the installed package using ORIGIN feature. Past experience suggests that INDEX is very poor source of dependency information due to its stale-most-of-the-time nature. > I came to the conclusion that this wouldn't really fit inside > bsd.port.mk, and it would be best to create a standalone pkg_upgrade > tool that mirrors portupgrade. Writing it in sh might be possible, > but it would probably get very complicated. As a first step I was > thinking about writing some C code that wrote INDEX into a binary DB > file, and which could read that into a tree structure in memory to > discover the dependency graphs. I don't know when I'll get time to > work on this though. Hm, execuse me my sarcasm, but do we really need the second portupgrade in C??? -Maxim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030420235156.GA47321>