Compatability with FreeBSD Ports

[Joerg Sonnenberger]

On Tue, Aug 16, 2005 at 12:39:23PM -0700, Chris Pressey wrote:
> 
> No, I am talking about a system of available classes of objects, and
> their behaviour - how each of them is allowed to execute commands.  It
> is "white" only in the sense that it describes what behaviour is
> allowed, and prohibits everything else.  But it is not the same as
> merely a list of allowed commands that can be arbitrarily executed,
> which is what I think of when you say "white list".

Well, I think you get most of this behaviour by classifying the files
and allow automatic registration based on that. It would reduce the need
for custom install scripts by a big deal. The rest is most likely very
specific and can't be handled very well by a classification.

> > packages are used to setup machines, they are a valid mean to automate
> > most of the configuration. This is not done for the typical packages,
> 
> Because it is a *different problem*.  That's no longer package
> installation.  That's system configuration.  I don't think they should
> be conflated in the same tool.

It's one of the typical examples of why to use custom packages :-) I'm
also pretty sure that if you have to manage a bunch of systems which are
mostly identical, that using the package management for configuration is
a valid use. A proper upgrade mechanism is a prequirement, of course.

You could separate configuration and installation phase like Debian
does, but that would shift only the problem.

> > but again Debian shows what can be done. Think about updating the boot
> > loader via package, you want or want not it to automatically reinstall
> > itself. Under Linux the problem of rerunning lilo after a kernel
> > update is a good example of why it should not be forgotten.
> 
> But do you have any *existing* examples?

Firefox. It builds the "registry" on the target system as part of the
install script. It's not 100% required, but the startup time increases a
lot without it. There are other examples where you have to register
parts of the package and I'm not sure if adding a class for each of this
helps so much. 

> Because, even if, in the future, updates to (say) the NetBSD kernel are
> under the domain of pkgsrc, I don't think it would have the same problem
> with its bootloader as Debian does with lilo.  (Correct me if I'm
> wrong.)  So this example is highly hypothetical, and unpersuasive to
> me... but regardless, I don't see why it couldn't be handled (and
> handled fairly well) by introducing a "kernel" class to the package
> system, if it came down to it.

Well, there's nothing wrong with using pkgsrc on Linux, so it is not
that hypothecial. The question is what is easier to maintain and verify
-- the scripts which are actually going to be run or a large list of
classes which cover all absurd cases.

> > > This analogy is specious because all userland programs do
> > > *different* things, while all packages have the *same* things done
> > > to them - "be installed", "be removed", "be upgraded".
> > 
> > *most* packages are as simple as install - remove - upgrade. Some are
> > more advanced.
> 
> You're not telling me which ones - or *why* they have to be treated as
> "more advanced" - so I'm getting suspicious.  :)

Look at the OpenOffice :-) More advanced is not a good thing here.

> > > To be clearer on some (not necessarily all) points, I find:
> > > 
> > > - pkg_*(1)'s methodology (specifically, directives in plists) to be
> > >   messy and insecure;
> > 
> > While some parts can be improved (e.g. reference counting for
> > directories, automatic handling for certain file types), I don't
> > see what is messy and insecure here. 
> 
> @cwd, @exec, @unexec.

@cwd is mostly used to save space, in pkgsrc everything goes under
/usr/pkg by default anyway. Situation can be a bit different for
pkgviews. BTW, this should normally (if not always) be automatically
created by pkg_create. For exec and unexec, well, they are used e.g. to
register texinfo pages and the like. They could be replaced by proper
mechanisms, I think OpenBSD did a lot in that regard lately. In all
other cases, they should be replaced by real install/deinstall scripts.

> It is quite enough *if everything else is set up correctly*.

That's why I said lol. Reality doesn't work like that.

> Setting everything else up correctly *is not best viewed as just a
> matter of scripting a bunch of commands*.

How should it be viewed instead? After all, it boils down to exactly
that.

> 
> > As Hiten asked for reasons to choose pkgsrc over
> > ports, I'll repeat one. pkgsrc ensures that configure doesn't see
> > anything it should not see.
> 
> This is in fact an example of what I was talking about below - the bulk
> of the complexity of the package-build system is about system
> organization, for example how the filesystem is organized.  It is not
> just about "scripting commands" as you suggest - unless you insist on
> looking at it at that level, which I suggest is decidedly suboptimal.

Setting up what should be visible is nothing more than setting some
flags and a bunch of conditionals to handle the various cases. It
doesn't matter whether you look at it imperatively or functional or
whatever, the amount of code doesn't chance very much. It's perhaps just
a preference whether a list of ifs or a list of Prolog rules is nicer,
but it doesn't change the complexity of the code at all.

> > It's setting a
> > few variables, sometimes a bit of patching around idiosyncraties. The
> > policy which decides the values is something completely different.
> 
> The policy decides those commands, at a higher level of abstraction. 
> The commands are merely a consequence - an artefact, even - of the
> policy.  The policy is what the programmer should be working with - not
> the commands themselves, any more than a C programmer should normally be
> working with assembly.

*sigh* The policy is what most programmers are using, that is layed out
in the normal Makefiles in pkgsrc. There are exceptions, because it is
sometimes a lot simpler to write two commands in the post-extract rule
instead of changing a policy. Sometimes the policies have to be tweaked,
that's why lazy evalutation is handy.

> Although I'm no fan of the buzzword, the ideal one would be
> "domain-specific" and almost certainly not invented yet.

So you suggest switching to different language, invest the time to
maintain it, fix the bug, learn the language. Sorry, I don't buy that.

> > The typical candidates either make the scripting
> > part necessary much more complicated
> 
> So you keep asserting, but on what reasoning and evidence?  That it is a
> few more keystrokes to type sys("foo") than it is to type just foo?

Yes. Especially if you add quoting and proper variable expansion. make
is not ideal for that, but well understood. 

Joerg