Date: Thu, 30 Mar 1995 02:57:14 -0800 From: asami@cs.berkeley.edu (Satoshi Asami/=?ISO-2022-JP?B?GyRCQHUbKEI=?= =?ISO-2022-JP?B?GyRCOCsbKEIgGyRCOC0bKEI=?=) To: jkh@freefall.cdrom.com Cc: ports@FreeBSD.org Subject: Re: Let's make the packages/ dir look clean! Message-ID: <199503301057.CAA07528@silvia.HIP.Berkeley.EDU> In-Reply-To: <28421.796509477@freefall.cdrom.com> (jkh@freefall.cdrom.com)
next in thread | previous in thread | raw e-mail | index | archive | help
* This sounds good to me, though I might ask whether or not it would also
* pay dividends if we were to seize this opportunity to CATAGORIZE the
* packages at the same time. We should come up with a <pkgdir>/<catagory>
* scheme where the packages are dumped according to where they came from
* in the ports hierarchy.
I'm not sure how we can go about doing this, as there isn't any
information about the category name in the Makefiles right now. We
can try to get it from ${.CURDIR}, but the parent directory name is
not necessarily the category name (e.g., if you "cvs co" the port).
The only way I can think of implementing this is to add a new variable
to all the port Makefiles, which is of course not too hard.
* using a LINKS type of scheme, it should also
* be possible for a package to link itself into multiple catagories
* and thus provide a de-facto "ueberpackage" scheme like Paul T. was
* talking about - my installation program can just get the top level
* directory names (some of which will represent ports catagories and
* some which won't) and show the various packages within it as the
* contents of the ueberpackage.
If you are suggesting to put that framework into bsd.port.mk, I think
that's overkill. All we need to do is to create some extra
directories under the ftp site's packages area and populate it with
appropriate symlinks. That whole thing will then get on to the CDROM
too.
Satoshi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199503301057.CAA07528>