Jordan K. Hubbard wrote:

This would still require someone to choose/write the "pkg" program,
and then make all invocations of "install" go through this layer...

Yep!  That's the basic idea.

Unfortunately choosing an existing program (such as rpm) means that it isn't optimally built for the task, and building a whole new program (such as xpkg) complicates the task enormously.

So at this point it has only built packages missing a few things (such as the variants or images) for an external program, or built complete packages for an internal program that is missing a few things (such as an implementation). And neither was very "popular" (slight understatement) with users that want to build from source anyway, and were not using packages. At least that was where it left off, as I remember it.

And both using the RPM package manager and writing a new one was tried (with "dp_light" and "xpkg"), neither solution has been very popular ?

I don't know if "popular" would be the word I would use. Neither solution has ever actually been *completed* would be a more accurate statement, so the resulting popularity of said solution is impossible to gauge. The MacPorts project has always had a rather lackluster attitude when it comes to the challenge of packaging up and delivering software to end-users, but the fact remains that most end-users just want to say "I want this, that and that other thing over there - make it happen please!" with the minimum amount of downloading/build time.

And simply having the solution available does not automatically mean that binaries will be. For instance Fink has their .info -> .deb wiring pretty soldered up already, but there's still no official binaries. I'm hoping that the MPAB project will at least get the building (with logging) part going. And that the MPWA project will do a better job of presenting these to the end-user. But I do believe it's going to use archives only, even if it could build "external" rpms and pkgs too.

If you look at FreeBSD ports, for example, where it could easily be said that a "sophisticated audience" is the target (FreeBSD's historical attempt to grab Linux mind/marketshare notwithstanding), most users actually install software by typing "pkg_add -r gimp" and letting the package management system do the rest, they don't think of "cd /usr/ports/graphics/gimp; make all; make install" as the most convenient/desirable way of doing it, and why should they - the latter approach takes at least 10X the time to complete.

I think I used "portinstall -Pp" instead, because it did a better job at sorting out dependencies. But I could only get binaries to work for a while, once I had installed something from source it started throwing dependency errors like missing symbols and such until I had upgraded and rebuilt the other things to match. Installing KDE took all weekend, for instance. My limited understanding is that only the releases are offered as binaries (packages), and the interim software updates are only offered as source (ports).

The simplistic alternative here was to continue with the old archives,
and just enable "archivemode" to create them before any installation.

Too simplistic, I think. Again, installing a package is not simply "de-archival" or we'd have taken that approach a long time ago. Just grep through the current macports collection for all the ports with pre/post install rules, for example. What happens with those? What you're proposing would essentially require an end-user to have the entire macports collection still on their hard drive so that they could simply skip the "build step" and de-archive instead, but still rely on the Portfiles for all the other install- time information/procedures. I suppose that's an incremental improvement, but I still don't think it's what users want in the final analysis.

The easy part of the archives was that it would still allow all the quirks from Portfile to continue working as before, whether it is about variants or post-activate actions or whatever else is buried in the Tcl. When translating these into packages, one would have to convert scripts and invent metadata to carry all features over and update the registry. It was my understanding that it was exactly the build step (and the accompanying need to install Developer Tools) was the one that most users was interested in skipping, not the installation of MacPorts. It could also be that Xcode Tools is 1000M and the Daily Tarball is 7M ?

And isn't so much of a suggested proposal, more like status quo... I prefer RPMS myself.

What users *really* want is a graphical front end that talks to a server somewhere "in the cloud" and pulls down an index of available packages for their platform (which pkg_add -r also does behind the scenes - if you're on Intel running FreeBSD-7, it grabs packages just for that, vs what happens if you're running FreeBSD- current on, say, a SPARC platform) then, because we're catering to Mac users and not FreeBSD users, allows the user to just click on the things they want, automatically pulling down dependencies and running the post-install actions as necessary.

The architectures was taken care of, and so was the operating system. The problems that we had with the RPM packages was that they didn't separate between OS releases, and the platform variants wasn't recorded (no variants were). So you couldn't separate between freebsd6 and freebsd7 or between darwin7 and darwin8, which means that you could end up with the wrong binaries. This was hacked up into a bogus "Requires: org.darwinports.${os}${major}" dependency, but it wasn't (and still isn't) very pretty... Even if it does provide the (repodata) index of the packages and their dependencies.

The simplest workaround was to use different URLs for different releases, and keep the simple os-arch (or cpu-vendor-os-gnu) designator within each package repository.

This is similar to the "package format" that Slackware Linux uses.
Has a couple of shortcomings, but at least it is simple enough...

Slackware's package manager also provides for install-time actions and tracks dependencies. There's more going on there than meets the eye. :)

Not all _that_ much more, though. Just the "do-inst.sh" and the optional dependencies (Slackware Linux doesn't use them, but other distributions such as Vector Linux do), unfortunately all the metadata is mixed with the content which complicates e.g. compression. And the part where it is not all similar is where Slackware packages uses simple text files and shell scripts, whereas the MacPorts archives would use fullblown Tcl programs (in form of a Portfile with support). Slackware packages and FreeBSD packages look rather similar, though ? Or at least they appeared that way to the Smart package manager... (http://smartpm.org/)

--anders

_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Reply via email to