Jordan K. Hubbard wrote:
>> *The language must be TCL? Shouldn't we think about using C
>> instead in the distribution service to avoid performance issues? The
>> compiling itself might be in any language, I think, but since we
>> already have MPAB let's keep in TCL.
>
> Now comes the hard part I've been hinting at from the very beginning. How to
> actually unpack the archive "fully" on the target machine. [...] Now we know
> that Portfiles are just Tcl scripts which use commands declared by the "Port
> system" (version 1.0 in this case), and in fact almost nothing of what you
> see above is in the standard Tcl command set but rather a part of the port
> system runtime, but the most relevant command here is at the very end:
> post-install
Many of the current Portfiles are trying to do *way* too much in Tcl, that
would be much better off integrated into base proper or implemented as an
extension. I think that making ports/specs/recipes into programs, rather than
markup with a tiny bit of dynamic content allowed is a mistake. But that's
another discussion.
> That deceptively simple little command is the reason we don't have binary
> packages *already*. Seriously. If we hadn't hit this issue and gotten into
> a big argument about how best to solve it, there would have been binary
> package support in the very first version of MacPorts that Apple released!
> The problem isn't the specific post-install rule that ccal is using, either -
> it's very simple, yes? A simple ui_msg to tell the user how to use ccal.
> The problem is that you can do *anything* from this rule and over 115 ports
> in the current collection do. They use it for creating custom users in the
> accounts database (if you install postgres, for example, it needs a postgres
> user account to run as), they use it for emitting helpful "post installation
> comments" as you see above, they can create special symbolic links or create
> custom configuration files, etc. Go grep for post-install in all of the
> ports today and you will quickly come to realize the scope of the problem,
> and
that's just today with a comparatively small 7870 ports in the collection
(FreeBSD has over 22000).
> This isn't the only bit of "intelligent runtime" behavior, of course. The
> package install command (lets call it ``pkg'') also needs to follow @pkgdep
> lines in that +CONTENTS file in order to install dependent packages (ccal
> doesn't have any, but most ports do) and possibly other bits of post-install
> behavior that folks have come up with (I think there's even a fancy way of
> adding user accounts now, but I could be wrong). All of those commands need
> to be run at the very end of a "pkg install ccal" command, and that means one
> of two reasonable choices:
>
> 1. pkg needs to be able to instantiate a tcl runtime environment that can
> pull in all of the port 1.0 Tcl files such that the post-install (and any
> other special post installation procedures) can run with the full
> environment, e.g. commands like "ui_msg" will be present and variables like
> ${name} will expand properly.
>
> 2. We need to create a different set of "installation commands or scripts"
> that are associated with a port and specifically designed to run at
> post-installation time, e.g. instead of a post-install command in Tcl, we
> would have some sort of "install script" that is bundled with the port and
> merely relies on a few key environment variables to be set in order to run.
> Then all 115 ports which currently declare post-install need to be modified
> such that they use the external script instead, and the port(1) system needs
> to stop running (or looking for) the post-install command and instead chain
> to the script so that "port install blah" still does the same thing as "pkg
> install blah".
>
> Option #1 is the easiest from a perspective of not having to really change
> any existing ports, but then you need to solve the problem of how to install
> the ports infrastructure on a machine that doesn't already have it. The
> actual ports runtime is less than a megabyte or so, and it would be easy
> enough to create a package out of it and then @pkgdep it from every port
> built by MacPorts (this also assumes that the bit of infrastructure you write
> to follow @pkgdep directives will not depend on the port system itself but be
> part of the "bootstrapper").
>
> Option #2 is the simplest in terms of not having to instantiate a full Tcl
> environment instead of pkg(1), but you'd then have to change the way all
> ports/pkgs are installed.
>
> I honestly have no preference at this point given that Landon and I managed
> to argue ourselves into a stalemate over the question of port runtime
> versioning, how to deal with different architectures (there's not just a Tcl
> piece, but also Pextlib) and blah blah blah, and in hindsight I think we
> vastly overcomplicated the problem in our minds. The actual implementation,
> particularly now that we've learned that the port system never versions
> (we're still at 1.0 how many years later? :)) and there's really only one
> architecture working caring about now (x86_64), of option #1, should you
> choose to go that way, should be pretty easy to get to "good enough" status.
>
> Note that I'm also glossing over details concerning direct vs image mode and
> whether an activate step is needed in pkg(1), in which case everything I said
> above about post-install also applies to pre/post-activate commands.
>
> I realize that this is a little long, but I figured the least I could do to
> atone for the lack of binary packages being in MacPorts from day 1 was to
> describe the problem space in as much detail as I could recall... HTH!
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
