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

    -d <pkgspec>
	(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.

    -p <PLIST>|<pkg_tarball>
	(purge) Unregister (and remove) any files that would
	be overwritten by the new package (from the -SO cognate
	packages).

[The next step is to do either "make install" of the new (or reverted)
package, or a "pkg_add -a".]

    -c <pkgspec>
	(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.

    -a <pkg_tarball>
	(add) Short for "pkg_hack -d <pkgspec>; pkg_hack -p
	<pkg_tarball>; pkg_add <pkg_tarball>; pkg_hack -c <pkgspec>".

Some Notes:

	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.


Frederick