Subject: Re: Auto-generating PLIST vs. FAKE
To: Marc Espie <Marc.Espie@liafa.jussieu.fr>
From: Hubert Feyrer <firstname.lastname@example.org>
Date: 09/05/2000 23:36:02
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
> 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 Feyrer <email@example.com>