[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Is it _really_ dead?

On Mon, Oct 16, 2000 at 04:11:17PM -0400, Mark W. Eichin wrote:
> And there we disagree...  anything less than proper dependency-aware
> upgrade simply doesn't count.  This is a *hard* problem which is why
> so much of the value of dpkg is in the "interesting" cases it
> handles.  It would be nice to see that independently appear in
> openpackages, but we've got this perfectly good dpkg over here that I
> at least see as so far ahead in this regard that it is a different
> game altogether... and while I don't have time to go
> teach/tech-transfer the years and years of work that go into that part
> of dpkg, I *do* have time to attempt to apply it directly.
> Does that help make it clearer what is going on here?

I'm going to be a bit of a curmudgeon:

I think the "right" way of getting dpkg support for bsd is to rebuild

I'd like to see a mechanism where "make install", with all its various
independent steps, has semantics equivalent to a dpkg install:

	* all installed files are entered into the database under
	the same package name.
	* there's a version associated with the install
	* if the install dies before completion, the installed
	files are backed out

I'd like to see support for extra-"package" dependencies and conflicts.

I'd like a mechanism to mark certain files as conffiles.  [To do this
right, I'd want the user to be able to declare such things, outside
the package, and the software author to declare such things, inside
the package.]

I'd like a mechanism to look at binaries (using ldd or some such) to
automatically place some basic dependencies on requisite libraries.
[No versioned depends unless specifically asked for.]

Ideally, this would use the same database format as dpkg which would
allow regular debian users to manage locally compiled software with a
minimum of fuss.

I suspect that to do this "as foolproof as possible", I'd need a libc
replacement (LD_PRELOAD hack, probably -- I worry about overly smart
build processes, but presumably any such problems could be treated as
fixable bugs).  Otherwise, a smart "install" executable would probably
do the trick.

In my opinion, debian packages should be a part of a smooth continum
that includes historically popular ways of installing pieces of software.



Reply to: