Date: Tue, 9 Jul 2002 19:14:17 +0200 From: Rahul Siddharthan <rsidd@online.fr> To: John Baldwin <jhb@FreeBSD.org> Cc: arch@FreeBSD.ORG, Dan Nelson <dnelson@allantgroup.com> Subject: Re: Cleaning old packages (was: Package system flaws?) Message-ID: <20020709171417.GA69932@lpt.ens.fr> In-Reply-To: <XFMail.20020709124717.jhb@FreeBSD.org> References: <20020709161953.GA69779@lpt.ens.fr> <XFMail.20020709124717.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin said on Jul 9, 2002 at 12:47:17:
>
> 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.
That seems rather ambitious, and too drastic a change, to me. What
I'd like to see is probably more like, the gfoo port needs gtk+ 1.2.6
or above, but not gtk+ 2.0 and above (incompatible) and not gtk+ 1.2.5
or below (buggy). There should be some way to specify this in the
makefile of the port, so that any port-management program like
portupgrade can make use of the information.
Right now, dependencies are typically specified by files (binaries or
shared libraries) which are searched for before proceeding. This is
better than a "hard" version number requirement and works a lot of the
time, but not always.
I'll have a stab at writing something in some scripting language. I'm
planning to try and implement some of the following features, for a
start, which I think can be done without any modification to the
existing ports tree/system:
(1) Upgrade dependencies only if essential, and then too only after user
confirmation, perhaps listing the possible affected packages (to
avoid things like the libpng chaos some time ago). Perhaps allow
"pinning" to a certain version number, so that it will never be
upgraded unless you manually "un-pin" it.
(2) When upgrading dependencies, provide a way to safely remove old
versions of duplicate packages, as I described in my earlier mail.
(3) Automatically generate the +CONTENTS file by first doing a "fake"
install in a temporary directory (assuming the port honours
$PREFIX), then moving the contents to their final destination (a la
gentoo). If your temporary location is on the same filesystem as
the final one, it won't even take additional disk space, and very
little additional time. Is there any obvious drawback with doing
this?
If anyone is interested, the gentoo portage system is described here:
http://www.gentoo.org/doc/portage-manual.html
- Rahul
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?20020709171417.GA69932>