On Thu, Jul 08, 2010 at 12:03:47PM +0100, Stuart Henderson wrote: > On 2010/07/08 11:50, Marc Espie wrote: > > each time xenocara farts, we get new libs (or less libs). > > in order for updates to work, we *should* propagate those changes to > > @wantlib in each port. > > > > This currently isn't done automatically... check-lib-depends is sloooww > > (needs to check every file before packaging) and not even flawless. > > > > I'm beginning to think we should split *most* of the related info info > > a separate file, so that updates can be done automatically (for the most > > part). > > > > Briefly, the only info that changes is > > - p* numbers (e.g., PKGNAME = somethingpN) > > - WANTLIB for the affected package. > > > > As much as I don't like adding, as naddy would put it, "more magic", I think > > the p* numbers could live in a separate file, along with most WANTLIB. > > > > e.g., we would have something like: > > > > REVISION-main = 5 > > REVISION-a = 2 > > > > WANTLIB-main += foo bar > > WANTLIB-a += x z > > > > in a separate file (say libinfo) > > > > (or we can even have this in the main Makefile, with proper markers for > > auto-update). > > > > Each time check-lib-depends runs, it would update this file... > > > > People could also update the REVISION* numbers carefully. > > > > (having WANTLIB += is because in some cases, we do need to have basic > > wantlib > > first) > > > > > > I'm going to see if I can make check-lib-depends "perfect". > > > > I'd like a bit of input about this scheme... > > > > I like having REVISION defined separately from PKGNAME, it will > definitely makes it easier to update in batches, and removes a source > of possible errors. > > I'm less keen on having this in a separate file - I see why you want > to do this but I think the disadvantages outweigh it - slower checkouts, > more inodes, cvs conflicts in more files, and until every existing > port is moved over I think the inconsistency between different ports > will be a source of confusion.. > > I would be happy to have this in the main Makefile with markers (and > also to require certain standards for WANTLIB entries there to allow > automated updates - e.g. I think requiring separate += lines rather > than \ continuations is probably a good idea here). Of course we need > to cater for other WANTLIB entries e.g. for the cases when a flavour > adds new wantlib.
I expect that specific FLAVORS will still require manual intervention. That's one reason for the WANTLIB += adding extra stuff if it's not detected is very simple. Separate file vs same file: + upstream-specific churn will show up only in that file + easier to update automatically - more inodes. - cvs conflicts (I doubt it will matter that much). I guess I can make a combination of introspection (reading existing values directly with make show=VALUE) + automatic modification (touch only a part of the Makefile that's explicitly # XXX don't touch) to put things in the same file...
