Date: Tue, 5 Sep 2000 22:44:07 -0500 From: Will Andrews <will@physics.purdue.edu> To: Steve Price <sprice@hiwaay.net> Cc: Will Andrews <will@physics.purdue.edu>, FreeBSD Ports <ports@FreeBSD.ORG> Subject: Re: Ports Options Paper Message-ID: <20000905224407.X23702@radon.gryphonsoft.com> In-Reply-To: <20000905221216.A25531@bonsai.hiwaay.net>; from sprice@hiwaay.net on Tue, Sep 05, 2000 at 10:12:16PM -0500 References: <20000903052226.E1205@radon.gryphonsoft.com> <20000905221216.A25531@bonsai.hiwaay.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Sep 05, 2000 at 10:12:16PM -0500, Steve Price wrote: > Thank you Will for the proposal. You obviously spent a great deal > of time thinking about this. Maybe I'm being a stick in the mud or > maybe it is just too many years of formal training but I think we > need to take a couple steps back and define what the Ports Collection > is and derive a set of requirements for what we want it to become. > Then we can design the system, code, test, code, test, ... ad > infinitum. Sprinkle in a few redesigns, nix UML diagrams and use > cases, and you almost have a formal design instead of the long series > patches upon patches that we have today. Don't get me wrong I really > like what we have today but there is always room for improvement. I > also know many of you are saying that this is a volunteer project and > you didn't come here to do formal designs and many of you including > myself do this all day every day now. Please bear with me it doesn't > need to be extremely formal. We just need to lay the groundwork > before we jump in and code so we don't end up back in the same place > as we are now a couple of years from now. Ok? 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. Someone suggested collapsing the ports into a XML file, and that might work if we had something that could parse the XML files and perhaps pipe a Makefile to make(1). However, this is a separate project from mine; all it does is change the interface between the actual ports and the core Makefile macro interpretations. It'd be a nice one, I suppose, but less important because it just involves optimization in terms of inodes and space, and doesn't really create any new features of any sort. > So what is the Ports Collection? One definition could go something > like this: The Ports Collection consists of two subsystems: the > ports tree and a set of package management tools. The ports tree is > responsible for building the packages used by the pkg_mgmt tools. > The pkg_mgmt tools allow one to seemlessly (painlessly?) manage the > installation/removal/upgrade of packages. Does this imply that > nobody will use the ports tree except Satoshi and a few brave souls? > Maybe. Depending on our goals (and their associated requirements) > we might come up with a system where nobody every has to use anything > but the pkg_mgmt tools unless they are expressly building packages. This doesn't really redefine the Ports Collection. I'd never use packages; I'm a freak and like/prefer to build everything myself. :) The way I currently see the Ports Collection, it is divided in two parts - from-source building and installing; from-package installing and management. > Is there a unique set of requirements for the ports tree and the > the pkg_mgmt tools? Is there overlap and if so how do they interact? > For instance, should the ports tree transparently handle upgrades, > just the pkg_mgmt tools, or both? Does the ports tree have special > requirements for the package format or just the pkg_mgmt tools? 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. This is what I'm trying to do with my proposal (seriously though, other people came up with proposals to do the same thing, long before I did). I'm trying to actually implement a decent upgrade mechanism. > Maybe a good place to start would be to define the characteristics > of the new Ports Collection and try to get at a set of requirements > from there? What are the characteristics of the current system that > need to be preserved, changed slightly, or completely overhauled? > What are some things missing in the current system that are desired > in the new system? 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. Additionally, the current system does not allow for a non-hackish method of preventing unauthorized dependencies (some configure scripts use a library if they find it, even though you didn't ask to link with it). And in addition to fixing this problem, we can also add a method to allow seamless option upgrades - i.e. if a user wants to update all the ports, then the options are preserved through upgrades, by default. > A friend of mine from GE once told me about the SMART principle as > it relates to requirements gathering - S?, Measurable, Attainable, > R?, Testable. Remember before you blurt out that 'the ports tree > shall use the minimum number of inodes' that this really isn't > attainable. In my mind the minimum number of inodes is zero and I > don't think we can construct a useful replacement for the Ports > Collection that requires zero space. :) Heheheh. Welcome to particle physics and optimization.. > If you've made it this far... Thanks! I'll try to refrain from > extended rants for awhile since after this I'm probably well above > my quota. No, you're not even close. I'm going to start ranting if people don't reply to something in the options thread - because this discussion's purpose is to decide the future of the ports collection. People should speak their heart's content and have their say. That said, I'm going to bitch real soon.. -- Will Andrews <will@physics.purdue.edu> <will@FreeBSD.org> GCS/E/S @d- s+:+ a--- C++ UB++++$ P+ L- E--- W+ N-- !o ?K w--- O- M+ V- PS+ PE++ Y+ PGP+>+++ t++ 5 X+ R+ tv+ b++ DI+++ D+ G++ e>++++ h! r- y? 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?20000905224407.X23702>