Re: debmake & dpkg
On Sun, 29 Dec 1996, Christoph Lameter wrote:
> On Mon, 30 Dec 1996, Richard G. Roberto wrote:
>
>
Richard did say this:
> richr >> - automatically install packages depended on by a package
> richr >
but he didn't say this:
> richr >This should be an option. Some people run stuff in /usr/local
> richr >instead of .debs. We should be able to force an install without
> richr >automatically installing dependency packages if we want.
> richr >
> richr >Although I don't know what depends on it, I am still running the
> richr >upstream ypbind. Probably not a good example, but you get the
> richr >point.
I know that you "like" this quoting technique, but from the point of view
of someone comming into a thread late, it is very confusing...
>
> Might dpkg need an option to tell it that a package is locally provided?
>
> i.e. do
>
> dpkg --local-package ypbind
>
This would be truely wonderful! Much of the "hate mail" about the
packaging system this last round has been about "local" packages not being
able to satisfy dependencies. This is a much needed enhancement for dpkg,
and I think this is the correct way to do it. There should also be a
feature in dselect (and it's ofspring) that lets you easily declare the
packages that are installed locally, so it can make the requisite calls to
dpkg.
> and thus all dependencies on ypbind are satisfied without consulting the
> database?
>
> richr >
> richr >FWIW, it all sounds good to me. I wonder how much of this is
> richr >related to the work Dale is doing on the dselect backend
> richr >interface?
>
> I think dselect and dpkg need to be two different packages. Perhaps we can
> make the dpkg-library a third?
>
This works for me. Don't forget dpkg-dev, which should eventually enclude
some form of deb-make.
With respect to deb-make, I have a few things to say. Please don't take
this a personal criticism Christoph. I have the highest reguard for your
programming skills, and you are the most prolific maintainer on the
project to date. (Who else puts out 3 releases in one day!)
My problems with deb-make are of a philosophical nature. When I build a
Debian package from upstream sources, I know where in rules or pre/pos
inst/rm scripts I do the various organizational jobs required to make the
package fit into the Debian mold. So, when I recieve a bug report that
such and such has the wrong permissions, or isn't compressed, etc... I
know right where to look to fix it. With deb-make I need to understand
what it does before I know where to look. Christoph's prolific nature make
this product more of a moving target than the kernel and as such, I have
been unable/unwilling to invest my meager resources in trying to keep up.
For simple, uncomplicated packages where all the issues are clear deb-make
appears to be a wonderful boon to the package maintainer, specially if the
package has regular changes comming down the pipe. But, for more complex
packages, like libraries and multi binary source packages, it's
capabilities are still "in development".
Because there are others who feel as I do, there will be some packages
that use deb-make and others that don't. This just adds another level of
confusion to the current swamp of package management.
Because of this, I would suggest that deb-make not go into dpkg-dev until
it is clear that it does the job across the board.
Later,
Dwarf
------------ --------------
aka Dale Scheetz Phone: 1 (904) 877-0257
Flexible Software 11000 McCrackin Road
e-mail: dwarf@polaris.net Tallahassee, FL 32308
------------ If you don't see what you want, just ask --------------
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: