Date: Sat, 9 Sep 2000 00:32:38 -0500 From: Steve Price <sprice@hiwaay.net> To: Will Andrews <will@physics.purdue.edu> Cc: ports@freebsd.org Subject: Re: Ports Options Paper Message-ID: <20000909003238.A92984@bonsai.hiwaay.net> In-Reply-To: <20000905224407.X23702@radon.gryphonsoft.com>; from will@physics.purdue.edu on Tue, Sep 05, 2000 at 10:44:07PM -0500 References: <20000903052226.E1205@radon.gryphonsoft.com> <20000905221216.A25531@bonsai.hiwaay.net> <20000905224407.X23702@radon.gryphonsoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Sep 05, 2000 at 10:44:07PM -0500, Will Andrews wrote: # Personally, I don't see any problem with the ports collection's current # definition. I just think that it needs to add better packaging support. # I'm not really sure I want to go to the trouble of redefining what the # ports collection is. Right now, I like the way it is just a huge set of # Makefiles and such. Ok so don't redefine it. Put the definition in a couple of sentences or less and see if everyone sees it the same way. # This doesn't really redefine the Ports Collection. I'd never use # packages; I'm a freak and like/prefer to build everything myself. :) I rarely use packages either but that really isn't the point. The point is that both need fixin' and some of us are talking about one and some the other when what we should really be doing is looking for a solution that might address both at the same time. # The way I currently see the Ports Collection, it is divided in two parts # - from-source building and installing; from-package installing and # management. Which is basically what I said... Now we're getting somewhere. Let's list the deficiencies with each system, qualities that no matter what solution we come up with we make darn sure they make it back in intact, and things that just need minor tweaking. # The only overlap at this time is the PLIST generation and the management # etc. that is done by pkg_create(1). Personally, I like this method, and # would prefer it to stay this way. IMO, both methods of installing # should allow seamless upgrades, but only one (packages) should be # REQUIRED to do seamless upgrades. People who don't like the lack of a # guarantee regarding ports' upgrade mechanism can just use packages. See this assumption can be the foundation for several requirements. We either allow seemless upgrades from the ports tree, the packages, or both. I'm leaning towards doing it for the latter and seeing if we can leverage that work for the ports tree. However, this is just a guess without having all the requirements laying in front of me. # I think the current system could be a lot friendlier, and that is the # goal with the options file; it can be parsed by a perl script to # generate a dialog(1) dialog file, which can then be used to generate a # Makefile.options to use the options a user desires. The problem with this (as Satoshi has already pointed out) is that this doesn't appear to work well for package building machines. -steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000909003238.A92984>