Compatability with FreeBSD Ports
Chris Pressey
cpressey at catseye.mine.nu
Thu Aug 18 11:31:52 PDT 2005
Just to tie this up:
On Tue, 16 Aug 2005 22:09:14 +0200
Joerg Sonnenberger <joerg at xxxxxxxxxxxxxxxxx> wrote:
> You could separate configuration and installation phase like Debian
> does, but that would shift only the problem.
What you call "only shifting" I call "seperation of concerns," I
suppose.
> > 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,
Then it's not a very good example.
> 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.
The number of classes would always be smaller than the number of
individual scripts, so it would inevitably be easier to maintain.
> > > 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.
By saying that they could be replaced by proper mechanisms, you imply
that you do not consider them proper either - so we agree, despite your
prior evasiveness.
> > 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?
As constraints on the organization of resources.
> > 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.
No, I do not suggest that. As I said in my last message, I am not
saying "don't use pkgsrc". By all means, use pkgsrc, if it is
better than ports.
What I _am_ saying is that there _are_ flaws in pkgsrc, and that we
should not be afraid of admitting that and talking about them. The
reaction I have seen from pkgsrc's advocates so far has not been very
graceful in that respect, however, and in that I am disappointed.
-Chris
More information about the Users
mailing list