Date: Sun, 14 Jul 2002 20:09:33 +0200 From: Thomas Seck <tmseck-lists@netcologne.de> To: freebsd-arch@FreeBSD.ORG Subject: Re: Package system flaws? Message-ID: <20020714180933.GA420@laurel.tmseck.homedns.org> In-Reply-To: <200207141624.g6EGOa0L033175@whizzo.transsys.com> 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> <200207141624.g6EGOa0L033175@whizzo.transsys.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Louis A. Mamakos (louie@TransSys.COM):
> > * 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.
A consistent package db is something I consider a vital part of the
system. If we had tools in the base system which could maintain it,
using portupgrade would simply be a matter of taste. In the current
state of affairs, I am forced to use it. And I am forced to install a
scripting environment I do not want. And all because of design flaws in
the ports and package system. And remember: This thread is about package
system flaws.
> Again, I don't see why it's so burdensome to type 'make install' in
> the /usr/ports/sysutils/portupgrade directory.
I am sorry that I am unable to make you understand my point.
> > 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.
No. They are told that they should do so. They could as well use cvs - it
would just be less efficient. You can even do binary updates if you
like.
> 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?
Again: My point is, that until portupgrade appeared on the scene, there
was no way to keep the package db consistent. This issue needs to be
addressed. portupgrade is a bandaid that should not have been necessary
in the first place. Period.
> 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.
I do not want to reimplement the wheel. Do not over interpret my
messages.
> 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."
This is not a matter of "taste" and personal dislikes. It is simply a
matter of how many dependencies you have to track to fulfill a task.
You can read all I have to say about this topic in
<20020713011750.GA755@laurel.tmseck.homedns.org>.
I will not waste any more bandwith in repeating this over and over
again.
--
Thomas Seck
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020714180933.GA420>