DragonFly BSD
DragonFly users List (threaded) for 2005-08
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Compatability with FreeBSD Ports

From: Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>
Date: Mon, 15 Aug 2005 22:04:25 +0200
Mail-followup-to: users@crater.dragonflybsd.org

On Mon, Aug 15, 2005 at 12:54:12PM -0700, Chris Pressey wrote:
> On Mon, 15 Aug 2005 21:03:02 +0200
> Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx> wrote:
> > On Mon, Aug 15, 2005 at 10:59:35AM -0700, Chris Pressey wrote:
> > > - package install/deinstall can execute arbitrary commands
> > 
> > This issue exists for every packaging system out there, simply because
> > it is necessary for proper operation.
> I disagree.  There is absolutely no reason that any package should be
> able to execute 'fdisk', for example.

Are you sure about that? What about an emulator for example, which sets
up the disk image to use? How do you want to determine which programs it
is allowed to execute? White lists are difficult to maintain and grow
very large and black lists have the same issue. If you do bother about
which commands will be executed, check the scripts first.

> > > - bsd.port.mk and friends are almost unreadable/unmaintainable
> > 
> > Well, anything comparable to bsd.port.mk or bsd.pkg.mk is a
> > complicated beast.
> Make(1) is basically the wrong tool for organizing something of this
> level of complexity - especially considering that 80% or more of what
> ports/pkgsrc does, has *nothing* to do with what make(1) was designed to
> do (dependency ordering & elimination of redundant actions.)

There aren't many proper tools around. E.g. plain shell is much better
either, Python not good for command scripting etc. I've looked at this
before and make is about as good or bad as many other solutions.

> > I agree neither with the unreadable nor with the
> > unmaintainable, at least for pkgsrc.
> How long do you think it would it take the average developer to read and
> understand the following code excerpt from bsd.pkg.mk?

Why does he have to? That's what e.g. the pkgsrc guide is (pkgsrc.txt).
I don't think the average developer can understand everything of libm
either, neither does he have to.

Actually, this code is easy to understand when you know how pkgsrc works
:-) It's just slightly convoluted by the logging.


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