Re: Compatability with FreeBSD Ports

[Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>]

On Mon, Aug 15, 2005 at 03:55:07PM -0700, Chris Pressey wrote:
> That's not part of package installation, in my view.  That's part of
> package configuration.  All pkg_add should be doing is putting the
> software on my hard drive.  It should not be setting it up for me.

Package installation can consist of things like restarting daemons.
Look at Debian, you might or might not agree with it, but it is
difficult to clearly cut lines. Also keep in mind that the
INSTALL/DEINSTALL scripts are certainly not the most dangerous parts of
a package. Limiting their use by anything but policies can easily hurt
for those cases where you really need the advanced possibilities.

Nevertheless can a lot of the install/deinstall scripts be handled by
more appropiate means, both ports and pkgsrc leak in that area compared
e.g. to OpenBSD.

> > If you do bother about which commands will be executed, check the
> > scripts first.
> 
> I shouldn't have to audit 'N' individual package-scripts when all that
> is needed is to make the *one* package system running them secure.

That's like saying "I don't need to audio 'N' individual userland
programs, whenn all that is needed is to make the *one* kernel running
them secure". It's been tried a lot, most attempts failed.

> One of the reasons our package tools (and many other tools) are not very
> good is because package management is not essentially a "command
> scripting" problem (nor are many other problems.)

bsd.pkg.mk is NOT about package management. It is about building
packages. Don't forget this difference, it is important. Building is
exactly nothing but scripting a bunch of commands.

If I can once more stress the comparision with Debian, it's the
difference between dpkg-buildpackage and dpkg/apt-get. There are a lot
of things to solve on the *package* management level, porting apt-get
would be a start. But don't mix or confuse them with with *build* level
problems. To look over to Linux, that's why Gentoo is so fragile,
because it also doesn't have a clear separation and binary package
support in Gentoo sucks even compared to the BSDs.

> > I've looked at this before and make is about as good or bad as many
> > other solutions.
> 
> How many of the tools that you have looked at are not essentially
> imperative?  Anything functional, deductive, declarative, dataflow,
> multi-paradigmal even?

No paradigm shift simplies the build problem, asI've already written.
You can improve make e.g. when looking at ant or jam, but the
fundamental solution is still a combination of build rules and
dependency tree. make might not be the perfect tool for something like
pkgsrc, but many of the difficult-to-grasp elements like lazy evaluation
are actually needed there. I have written by own Linux distribution, I
have started to write a build system in plain shell, I know Python well
enough to ignore it for this. A lot of things might be simpler for
pkgsrc when moving e.g. to jam, but it wouldn't change the basic
complexity. There are way too many irregularities out there.

> If the tools were made very simple, their evolution might even be in the
> hands of the users.  Imagine that!

Just because a tool is easy to use, doesn't mean it is easy to
understand. Just an example from the subject I study: the integrate
command of Computer Algreba Systems is very easy to use. You give it a
term, the independent variable and maybe also the limits, it computes
the closed-form of the integral if possible. The actual algorithm has
the size of the Bible, even Mathematica and Maple needed *years* to
fix most bugs. Does that make the tool of symbolic integrate less
useful? Does it make the tool more complicated?

> Is it acceptable to you that the average developer (never mind the
> average user!) is not expected to be able to understand the tools that
> they use?  What is the point of the source being "open" in this
> situation, when it's still effectively "closed" to most people?

There is a clear structure of steps taken during the processing. If you
follow this steps, it normally becomes quite clear what the code is
trying to achive. The big problems here are the various edge cases,
which are obstacles to understand. But exactly those edge cases create
the power of the system and allow the simple descriptive Makefiles in
most ports/packages.

> If it is acceptable to you, then I'd like to know: how do you reconcile
> this with your position of "if you're worried that a call to pkg_add
> might trojan your machine, you should audit the install script yourself
> before doing it"?

I don't like code which is too complicated to understand. I agree with
you on that. But sometimes complexity is necessary. That's what
documentation is for.

Joerg