Date: Mon, 19 Mar 2007 17:25:08 -0700 From: Doug Barton <dougb@FreeBSD.org> To: pav@FreeBSD.org Cc: Alexander Leidinger <Alexander@Leidinger.net>, freebsd ports <freebsd-ports@freebsd.org> Subject: Ports management tools in the base (Was: Re: cvs commit: www/en/projects/ideas ideas.xml) Message-ID: <45FF29E4.4060305@FreeBSD.org> In-Reply-To: <1174308178.15322.13.camel@pav.hide.vol.cz> References: <200703181638.l2IGcoaj003204@repoman.freebsd.org> <20070319125101.4lb7lljt5w4cwog8@webmail.leidinger.net> <1174308178.15322.13.camel@pav.hide.vol.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
Pav Lucistnik wrote: > Alexander Leidinger píše v po 19. 03. 2007 v 12:51 +0100: >> Quoting Pav Lucistnik <pav@FreeBSD.org> (from Sun, 18 Mar 2007 >> 16:38:50 +0000 (UTC)): >> >>> pav 2007-03-18 16:38:50 UTC >>> >>> FreeBSD doc repository >>> >>> Modified files: >>> en/projects/ideas ideas.xml >>> Log: >>> Add four new ports related entries: >>> 4) portupgrade in base thing >> Isn't portmaster something which would fit here already? I didn't >> looked at it, I just judge from what I did read in the lists. > > Possibly. But it still isn't either finished or in base. This thread started with the ideas page entry here: http://www.freebsd.org/projects/ideas/index.html#p-ports-upgrade In response to Pav's suggestion above, I haven't put portmaster in the base for a few reasons, the most important one of which is that my feeling is that the only ports related tool that should be in the base is pkg_add. I think that the rest of them should be ports themselves, which not only is cleaner architecturally, but also has a lot of advantages when it comes to things like adding new features to them. Another reason, for whatever it's worth, is that up till now no one has suggested that it go into the base (which is fine with me). As for it not being finished, is any software project ever really finished? :) I'm pretty close to the end of the list of features that I was ever interested in implementing, and I've added almost every feature that users have asked for (with the notable exception of installing packages). So I would classify the project as "mature," and if there is clamor for it to go into the base, I would be willing to do so. That said, I would have a great deal of concern over the idea of having something that implemented a lot of portupgrade's features in the base. I say this with all due respect to sem, and everyone else who's been involved in the development of portupgrade. I think it's a fine tool, and I am all for the idea of people developing and using tools that meet their interest and needs. I have never viewed portmaster as a competitor of portupgrade, and indeed I've said many times that it's not even on my radar to be working on a "portupgrade replacement." My concern is related to the idea of having such a tool in the base dramatically expanding the complexity of the ports infrastructure beyond what it is already. Personally I've noticed a lot of additional complexity that has been added since portupgrade first starting becoming popular, and my gut feeling is that a lot of things are done with the rationale "oh, they can just use portupgrade to fix things up after I'm done." If we want to re-architect the ports system so that it _requires_ some sort of database other than /var/db/pkg, fine. Let's have that discussion (which I realize would be the nightmare bikeshed from hell), but let's not back into it by adding a portupgrade-like tool to the base which becomes mandatory inch by inch. As for the requirements in the ideas page ... The required functionality is: * fixing @pkgdep records in +CONTENTS file * fixing +REQUIRED_BY records Portmaster already does these two, and that part of the code is very mature since it's one of the first features I wanted for myself when I started developing it. * storing old copies of shared libraries after shmajor number change in /usr/local/lib/compat/pkg Portmaster doesn't do this currently. I have mixed feelings about whether this is even a good idea or not. I'd be happy to elaborate on why if anyone cares. * upwards and downwards recursive modes If I understand you correctly, what portmaster does currently when building a port (a depth-first traversal of the dependency tree) would be considered downwardly recursive, and the -r function (ala portupgrade's) might be considered upwardly recursive, but I'm not 100% sure I'm right here. :) I think one meta-requirement that is implied on the web page but not stated is that the tool not rely on any features that don't already exist in the base. Since portmaster is written in /bin/sh, and doesn't rely on any databases to do its work, it meets that requirement. Now having said all that, I still want to reiterate my point that I feel the conversation we _should_ be having is moving all the ports/package management tools other than pkg_add into the ports tree, but if people are determined to put "a port management tool" into the base, then yes, I'd like portmaster to be considered for that role. Doug -- This .signature sanitized for your protection
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45FF29E4.4060305>