Hi,

I apologize for taking so long to respond, but I haven't gave up
my idea...

Date: Mon, 6 Nov 2000 16:46:32 +0100 (MET)
From: Hubert Feyrer <hubert@feyrer.de>
 > On Mon, 6 Nov 2000, Alistair Crooks wrote:
 > > 3. I'm not convinced that sub-packages are actually necessary, since most of
 > > their contents can be decided either by their location or by their
 > > filenames. 
 > 
 > I second this. I often do things like
 > 
 > 	$ pkg_info -qL somepkg | grep bin/
 > 
 > to find out which binaries the pkg offers.
 > 
 > > By doing things this way, you cut out a lot of the redundant
 > > information that would be in sub-package PLISTs, etc, and (I believe)
 > > obviate the need for adding to the syntax already in the PLISTs. e.g. in
 > > bsd.pkg.mk, we have a gonzo regular expression which matches the manual
 > > pages for all packages, which seems to work fine. The same could be done for
 > > bin sub-packages, lib sub-packages, example sub-packages etc. We're still
 > > running into the problems as laid out in (1) above, though.
 > 
 > One quick solution for pkg_add comes to mind; as it uses tar to extract
 > files, it wouldn't be hard to pass the files to extract that way:
 > 
 > 	tar bla.tgz bin/* share/* ...

I agree with you. The pattern matching approach is useful in many
cases. But I don't think it not work well in all cases. I believe 
that there are some cases in which we have some problem.

For example, 
  - core executable binary might need some files in lib/ directory.
  - shared obkects and static link libraries will be in same directory.
  - What shoud we do about @exec and @unexec directive?
  - Some packages have a install script in it. They might fail if some
    files were deleted implicitly.
  etc.

My point is, 

  It's better that you can describe the rule to choose files of the 
  subsets if you need or you want.

Don't you think so? And I think the pattern matching approach isn't 
in conflict with my proposal.

Takemura