From owner-freebsd-arch Sun Jul 14 9:24:41 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A1D6C37B400 for ; Sun, 14 Jul 2002 09:24:37 -0700 (PDT) Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 03EE343E64 for ; Sun, 14 Jul 2002 09:24:37 -0700 (PDT) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (#6@localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.12.5/8.12.5) with ESMTP id g6EGOa0L033175; Sun, 14 Jul 2002 12:24:36 -0400 (EDT) (envelope-from louie@whizzo.transsys.com) Message-Id: <200207141624.g6EGOa0L033175@whizzo.transsys.com> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Thomas Seck Cc: freebsd-arch@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: Package system flaws? References: <20020712121427.GD3678@lummux.tchpc.tcd.ie> <20020712144854.GA756@laurel.tmseck.homedns.org> <20020713054141.A26277@misty.eyesbeyond.com> <20020713011750.GA755@laurel.tmseck.homedns.org> <20020714042237.GD931@lizzy.catnook.com> <20020714042623.GB95460@squall.waterspout.com> <20020714095939.GA588@laurel.tmseck.homedns.org> <200207141333.g6EDXj0L031673@whizzo.transsys.com> <20020714155728.GA4237@laurel.tmseck.homedns.org> In-reply-to: Your message of "Sun, 14 Jul 2002 17:57:28 +0200." <20020714155728.GA4237@laurel.tmseck.homedns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 14 Jul 2002 12:24:36 -0400 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > * Louis A. Mamakos (louie@TransSys.COM): > > > If you've decided to install optional software on your system using > > the ports mechanism, then it doesn't seem too extreme a requirement > > that you install a port or package to maintain your ports/packages. > > Sorry, I cannot follow this kind of reasoning. The problem with > portupgrade is that you _need_ it to correct the flaws of the current > pkg_* tools. And the more people start recommending the use of > portupgrade to new users, the less likely it is that the real issues > with the ports/package system ll ever get fixed. And so what's so difficult to understand? Why is it that the only tools "qualified" for use in maintaining the ports on a machine seem to be required to be in the base system? From what I can tell, the direction is to move non-essential stuff out of the base system. Again, I don't see why it's so burdensome to type 'make install' in the /usr/ports/sysutils/portupgrade directory. > > cvsup isn't in the base system, but we manage to use it to keep both > > the base system and ports up to date. > > What has cvsup got to do with it? You can keep your sources up to date > with cvs too. cvsup is designed to be more efficient than cvs. It is not > a bandaid like portupgrade. And yes, I do not like the fact, that it is > written in Modula 3 instead of C{,++}. Those users that don't just install off of CDROM distributions, and try to keep up to date with the -STABLE branch or the HEAD of the CVS tree use cvsup to update their systems. At least when I was involved in running one of the CVS mirrors, the only server running was cvsupd. So there's an even more critical tool, only available as a port or package, in wide use. Why do you care what the implementation language of the tool is if it solves the problem? Shouldn't we be pleased there even exists a tool in the first place? > > I suspect the only result of an attempt to re-write sysutils/portupgrade > > in a different language will be that the current developer of that tool > > will disappear. I suspect he chose his implementation lanaguge for a > > reason. Do you want the tool and developer, or a version in awk/sed/C? > > Did you ask knu about it or is this speculation on your part? Again, I > did not say that the portupgrade _port_ should be rewritten. I meant > that one should re-implement the tools knu wrote and put them into the > base system as a short term solution. A mid-term solution would be to > correct the issues with the dependency handling within the base system. > When this is done, people should think about new ways to pack and > transport packages. I guess no one is stopping you from reimplementing your own wheel, er, tool to replicate the functionality of the one that's already working pretty good. And no, I haven't spoken to knu about his opinion. I based that remark on how I'd react if someone were to come along and say, "I really like your software, but I need you to re-write it in a language that I like for essentially no good reason." louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message