Subject: Saving old shared libraries, part II [was Re: install and update
To: Michael Richardson <email@example.com>
From: Frederick Bruckman <firstname.lastname@example.org>
Date: 05/31/2001 11:49:10
On Thu, 31 May 2001, Frederick Bruckman wrote:
> On Thu, 31 May 2001, Michael Richardson wrote:
> > I would prefer that if one has a dependancy like:
> > A --> B --> C --> D
> > (D depends on libraries C, B and A, Easy with gnome apps)
> > And I want to install:
> > A' --> Z
> > that A and A' can coexist. At least, that the files (i.e. .so's) for
> > A can coexist with A'.
Given that people keep asking for this, in spite of the evident
problems (see Part I), I'd like to propose a solution.
First of all, I feel it would be premature to add this functionality
to the pkg_* tools (considering those evident problems), so I intend
to create a "pkg_hack" utility with the following options...
(delete) Synthesizes an installed package consisting
of only the shared libraries from <pkg>. The new
package gets a unique name, generated by inserting
-SO- between the name and version number. The package
database is fixed up so that the new package adopts
all the fulfilled dependencies (REQUIRED_BY's) of the
old package, then the old package, including all
remaining files, is deleted.
(purge) Unregister (and remove) any files that would
be overwritten by the new package (from the -SO cognate
[The next step is to do either "make install" of the new (or reverted)
package, or a "pkg_add -a".]
(clean up) Clean up after "pkg_hack -d" &c. Any cognate
package that was emptied of all files by "pkg_hack -p"
will now have all it's fulfilled dependencies absorbed
by the new package.
(add) Short for "pkg_hack -d <pkgspec>; pkg_hack -p
<pkg_tarball>; pkg_add <pkg_tarball>; pkg_hack -c <pkgspec>".
Any sort of "atomic" update isn't particularly useful, since it
won't let you _build_ packages. The whole point is to make it
easier to update packages from source, for the benifit of
sysadmins who don't do binary packages, and for ease of maintaining
pkgsrc. The collection of released binary packages should never
be made this way. (See part I -- "intractable problems".)
If this were ever integrated into the pkg_* tools, pkg_info
would need to grow smarts to report on the -SO- cognates, and
"pkg_delete -R" and "-r" would need re-thinking, too.