Skip site navigation (1)Skip section navigation (2)
Date:      09 Jul 2002 21:10:07 +0100
From:      Simon Marlow <simonm@smarlow.com>
To:        Rahul Siddharthan <rsidd@online.fr>
Cc:        John Baldwin <jhb@freebsd.org>, arch@freebsd.org, Dan Nelson <dnelson@allantgroup.com>
Subject:   Re: Cleaning old packages (was: Package system flaws?)
Message-ID:  <m0ptxw3bog.fsf@sm.dnsalias.com>
In-Reply-To: <20020709171417.GA69932@lpt.ens.fr>
References:  <20020709161953.GA69779@lpt.ens.fr> <XFMail.20020709124717.jhb@FreeBSD.org> <20020709171417.GA69932@lpt.ens.fr>

next in thread | previous in thread | raw e-mail | index | archive | help
Rahul Siddharthan <rsidd@online.fr> writes:

> 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.

A port can't know which versions of a library it will be compatible
with ahead of time.  Only the port itself knows which older versions
of itself are compatible with the current version, so the information
about whether an upgrade is safe or not should reside in the port
which is being upgraded.  This why the suggestion of using capability
names or APIs to specify the functionality is a better way, but I
think it's perhaps a level of abstraction too far.

I've always been annoyed by the way the ports system spams older
versions of ports with newer ones.  It isn't safe to do in general, so
IMO the ports system should at the least just refuse to continue if it
finds it needs to do this.  Then if the specification for a port had
some way to say that it was safe to upgrade certain versions to the
new version, it could go ahead (deleting the old one first, of
course).

So here's my suggestions:

 - Allow a port to specify a range of versions which are safe
   to upgrade to the current version without user intervention.

 - The ports system should *not* automatically install a new version
   of a port over an old one.  If the port says it is safe to do so,
   then remove the old port and install the new one.

Allowing dependencies to specify version ranges would help reduce the
number of upgrades required, but wouldn't otherwise improve matters.
Also it requires updates to N ports rather than 1 for each dependency,
so is far more error prone.

(disclaimer: I'm lazy and haven't looked at libh, so I apologise if
this is old news)

Cheers,
        Simon

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?m0ptxw3bog.fsf>