> From: Paul Rogers <[email protected]> > Date: Mon, 30 May 2016 14:11:31 -0700 > Subject: Re: [blfs-support] Dependency chain > > > I do not think this is reasonable for a couple of reasons. First, we > > do not have the manpower to spend the time to figure that out. Second, > > it creates a maintenance nightmare because at every package update > > (often 3-5 per day, sometimes more), we would potentially need to to > > update the dependent packages for changes. > > Really? OK. I don't know your process. I figured it'd be trivial--as > you're updating each package, on each page you put a link to its > dependencies, just "click on it" and add the anchor pointing back. >
Core script is reasonably direct and clean - e.g.: == * parse the xml; * get table of package/dep-categ/dep-label; * use (repeated) sort/join cmds on orig+generated tables. * extracted wanted data from relevant table(s)+row(s). == However, as is well known, there are - e.g.: -- - circular deps; - some 'blurring' of 'required'/'recommended'/'optional' dep-categories; - some dep- sub-categories; - deps within book and some outwith; - blfs deps lists just omit entirely any ref to anything in lfs; - and other 'real-world' messiness. -- So in practice the above seq of 'naively'-generated tables, doesn't hit a natural finite clean end-point; and one needs to augment the 'raw' data with some of one's own 'logic'/rules that you essentially 'patch-in' to the orig tbl. (IOW, the real central issue is that the raw dep-logic is, as noted often(-ish), not a simple tree or even a DAG.) rgds, akh -- -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
