On Mar 27, 2011, at 1:58 AM, Anders F Björklund wrote:
> (continued, from premature send)
>
> Jordan K. Hubbard wrote:
>
>> 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).
>
> There could have been archives (pre-compiled destroots), even if the ports
> wasn't ready for binary archives.
>
> But in the first versions of MacPorts, it did build .rpm packages of all of
> the ports. Don't recall scripts.
Jeff semi-flamed me in a private email (Hi Jeff!) over not making specific
mention of RPM in my little screed, but as I said to him, sure we created a
bunch of files that ended with the .rpm suffix but we never actually created
"RPMs" in the full sense of the word.
>
>> 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.
>
> Maybe this is better handled by "port -b", if it needs the full environment
> anyway ?
>
>> 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".
>
> This would probably be better, either @exec/@unexec or something much more
> "tailored" ?
>
>> 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 think it would be best to *not* have a Tcl interpreter (and thus ignore
> +PORTFILE), as long as it can interact with the registry. It should have
> "enough" information in the +CONTENTS, even if it requires modifying those
> 115 out of 7870 ports that require it. Otherwise there isn't much of a
> difference between port(1) and pkg(1) ? But you would still need to
> re-implement all the other bits - like compression, signatures, depsolving,
> etc. etc.
>
>> 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.
>
> MacPorts spent a couple of years discussing the optimal logging format,
> instead of actually implementing it. So that seems rather common. Hopefully
> at least archives can be delivered this time, before moving on to packages.
>
>> 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!
>
> Fink has a better situation by using an existing package manager (dpkg), even
> if it's not without flaws. Like needing /sw and /sw64, instead of universal
> binaries. But at least it has had binary packages from Day 1...
>
> --anders
>
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
