Date: Tue, 09 Jul 2002 12:47:17 -0400 (EDT) From: John Baldwin <jhb@FreeBSD.org> To: Rahul Siddharthan <rsidd@online.fr> Cc: arch@FreeBSD.ORG, Dan Nelson <dnelson@allantgroup.com> Subject: Re: Cleaning old packages (was: Package system flaws?) Message-ID: <XFMail.20020709124717.jhb@FreeBSD.org> In-Reply-To: <20020709161953.GA69779@lpt.ens.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
On 09-Jul-2002 Rahul Siddharthan wrote: > Dan Nelson said on Jul 9, 2002 at 10:49:13: >> > new package. Suppose you had installed foo-1.3.1, and then another >> > port you were installing overwrote this with foo-1.3.2. Now both are >> > registered in /var/db/pkg but you can't pkg_delete foo-1.3.1 because >> > it will remove files with common names from foo-1.3.2. >> >> If you use portupgrade to install ports and packages, it will deinstall >> the old port before installing the new one. > > Since you're the third person telling me this (the first two were > off-list) let me clarify -- I know about portupgrade. Yes, if I use > only portupgrade and nothing else, I won't have the problem. But > using portupgrade all the time is totally unrealistic: (1) it has > problems with binary packages, and (2) I don't like rebuilding every > dependency which has had the most minor of changes every time I > install a new port. Besides, portupgrade is not part of the base > system, it's an add-on, so in my opinion saying "use portupgrade" is > not an answer. If you use the base system tools you *will* run into > the problem of duplicate installed packages, rather quickly. > > I was initially impressed with portupgrade, but after using it a while > I realized it solves problems which I don't have and not the ones I > have. Mainly, I want dependency tracking (which the ports system > supplies already) but I don't want to upgrade old packages > automatically unless it's essential or I specifically ask for it. As > others have pointed out, what's needed is using version ranges to > express dependencies. Or rather, to depend on abstract functions provided by other packages. I.e., package A might depend on the 'foo' functionality which is provided by package B. Thus, package A is not tied to B's specific version. If you have a new API then you can append a version to 'foo'. For example, you might have 'qt1', 'qt2', 'gtk12', etc. "functions". RPM does this and I think that the new /etc/rc.d stuff in current uses a similar scheme. RPM also supports the notion of a package having a function that conflicts with other functions. The idea though is that dependencies aren't strictly on a package, but on functoinality provided by that package. This does mean more work when trying to figure out how to fulfill a needed dependency, however. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ 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?XFMail.20020709124717.jhb>