On Tue, 5 Sep 2000, Marc Espie wrote:
> Let me clarify: there are two distinct automated packing-lists generators:
> - the one that's used to substitute variables (functionality that NetBSD has) 
> and to grab fragments (NetBSD does not have that as far as I know. I added
> it when I got tired of forgetting to update PLIST.unshared every once in a
> blue moon).
> That one is always used, and we try to make it as invisible as possible.

OK, for me that's not generating - it's only modifying. ;-)


> - the one that's used for the creation of a packing-list ab nihilo.
> That one is provide as an aid to porters in the tedious task
> of porting new software and updating old ports... Easier to do diffs than
> to get everything done manually, e.g., it is only a porter tool.

IC. I thought you'd only use this list, and nothing else, esp. nothing
manually maintained. 


> Having comprehensive packing-lists in the tree is useful to generate, for
> instance, a list of all conflicting packages directly from the ports (damn,
> pkgsrc) tree, so that informed decisions can be made globally, without needing
> to have all packages available, redundant ports, or pkgcfl directives 
> that were missed. 
> 
> >From a logistics point of view, this makes this check available to everyone,
> without needing the somewhat important space&time resources that might be
> needed to build a full package tree...

How many conflicts did you find that way that the ports' autors were not
aware of when they put files into a certain place? E.g. If someone makes
a pkg for netscape communicator and navigator, I'd expect to know him that
he'll have to deal with conflicting files. How many conflicts did you find
where it was *not* that obvious that conflicts appear?


 - Hubert

-- 
Hubert Feyrer <hubert.feyrer@informatik.fh-regensburg.de>