Subject: Re: Introducing a better way of updating packages (long)
To: None <>
From: Alistair Crooks <>
List: tech-pkg
Date: 05/17/2002 12:19:35
On Fri, May 17, 2002 at 10:04:34AM +0200, Julio Merino wrote:
> On Thu, May 16, 2002 at 08:45:00PM -0500, Frederick Bruckman wrote:
> > 
> > A solution:
> > ----------
> > 
> > So, this implementation follows the brainstorm I had nearly a year
> > ago (below)...
> > 
> > The first part of the idea, in brief, is to store these needed
> > files in a way that doesn't require any extension to the format
> > of ${PKG_DBDIR}, via the mechanism of creating packages "on the fly"
> > with reserved names. So when "libfoo-1.0" is deleted, "libfoo-SO-1.0"
> > appears, containing only the shared libraries formerly held by
> > "libfoo-1.0", while carrying over all the dependencies formerly
> > held by "libfoo-1.0". Despite it's dubious origin, this "libfoo-SO-1.0",
> > looks just like a regular package to the package tools: the dependents
> > reported by "pkg_info -R" are accurate, "pkg_info" over such
> > dependents accurately reports their dependence on "libfoo-SO-1.0",
> > and "pkg_info -L" lists the (few) files it contains.
> I like the idea, though I have a comment. Currently, to upgrade a package
> (lets say a library) I do:
> pkg_delete -f mylib
> cd /usr/pkgsrc/devel/mylib
> make && make install

Although it's still experimental, it's much easier to do

cd ...pkgsrc/category/package && make replace

since this will DTRT with the packages which depend upon this one.

> This works almost always, as packages can work with a slightly new version
> of the library. I think that -so-* packages should only be done if some
> package requires that version *explicetly*. That is, we usually tell pkgsrc
> dependancies with something linke: mylib>=3.24, that is, equal or over 3.24.
> So if we update the library to 3.25, there should be no need to keep 3.24
> if packages depend on 3.24 or over.
> This can be acomplished with freebsd's portupgrade technique... and this is
> the only problem I'm having now. As deinstalling a package, forcing it, you
> loose dependancy information. When updating a package of this kind, the old
> dependancy list should be kept and "copied" in the new package information,
> under /var.
> I don't know if I have explained it properly...
> Although I like it, and I hope this to be available "soon" ;)