Subject: Re: Sub package proposal
To: None <email@example.com>
From: TAKEMURA Shin <firstname.lastname@example.org>
Date: 10/23/2000 14:55:46
> >> The basic idea is that I want to install a part of a package. Mostly,
> >> I need man pages but I don't need document files. To do that, I want
> >> to introduce 'sub package'. We have to define some 'pre-defined sub
> >> packages', for example,
> >If I install 'core' and 'doc' of 'archivers/arc', what is registered
> >as installed, that is, how does it look like under /var/db/pkg? Like
> >'arc-5.21e'? Or 'arc-5.21e-core' and 'arc-5.21e-doc'?
> i assumed the former (arc-5.21e).
My idea is that /var/db/pkg/arc-5.21e/+CONTENTS contains
'@installed core doc' and dbm database has same information
If some package depends on other packages, i.e. the PLIST has
a @pkgdep directive like '@pkgdep foo>=1.0', pkg_add will check
whether core subpackage of the package foo is installed or not.
It it isn't installed, the installation will fail. (or pkg_add
might attempt to add the subpackage in the way which I wrote
other mail.) If a package depends on more than core subpackage,
you should put '@pkgdep foo>=1.0 ext dev' in the PLIST.
This story is only for binary packages. If you attempt to
build/install a package from pkgsrc, it expect that all
subpackages of depending packages were installed. I suppose
that most people will install all subpackages though the new
subpackage system were availavle. Users who don't install some
subpackages should take some risk.