Let's keep this discussion on the list. Be sure to use the Reply To
All feature when you reply.
On Apr 1, 2007, at 02:37, Bas den Hond wrote:
>> I'm familiar with the @version syntax for *uninstalling*, but I've
>> never heard of it for installing. I can't see that usage described
>> in the manpage either. Though if you see it there, please show me.
>> To the best of my knowledge, MacPorts has no such capability.
>>
>>
>>> So what gives? I guess I could remove the svn tree from
>>> sources.conf temporarily, but that seems klutzy...
>>>
>>> Any explanation appreciated.
>>
>> As I said, I only use my local svn working copy, and comment out
>> the rsync source. You might try that as well. With the svn working
>> copy you have the advantage that you can backdate any port to any
>> version. Simply use "svn log" on the portfile to find the last
>> revision number where the port was at the version you want, then
>> use "svn up -r" to download that version of the portfile. Then
>> "sudo port install foo" as usual, or if the port is already
>> installed in a different version, "sudo port -nf upgrade foo" to
>> force it to install again at the backdated version.
>
> Thanks, that explains a lot.
>
> I was assuming that Macports capabilities were orthogonal. That is,
> if the expression program@version means anything and can be used in
> an expression somewhere, it can be used everywhere... From a user's
> perspective, I think that should be the way it works.
It does not work that way, and it would be very difficult to
implement that, given current MacPorts structure. As far as MacPorts
knows, there is only one version of the portfile, which describes one
particular version (and revision) of the software, and you can
install that version and only that version. But you can specify
variants too. So you can end up with all of "php5 @5.2.1+apache2",
"php5 @5.2.1+fastcgi+mysql5" and "php5 @5.2.1+pear+sqlite" installed,
to show but a few examples. When it comes time to uninstall, MacPorts
needs to know exactly which one of those you would like to uninstall.
That's why the uninstall action accepts a version/variant specifier.
For situations where we want multiple versions of a software package
to be available, multiple ports are created. See for example mysql,
mysql4 and mysql5; apache, apache20 and apache2; php4 and php5;
sqlite2 and sqlite3; glib1 and glib2; and gcc33, gcc34, gcc40, gcc41,
gcc42 and gcc43, to name but a few examples -- and of course
wxWidgets26 and wxWidgets which you already know about.
> From that same perspective, I would urge the Macports developers to
> integrate the svn-trick into the port program itself. As things
> stand now, you think you're ready when you've read the port
> manpage, but eventually you discover you have to install and then
> learn svn, too, in order to manage any syncing problems.
You do not need to use or learn how to use Subversion in order to use
MacPorts (not that it's difficult). The reason I am using a
Subversion working copy for my ports tree is that I am a committer
and need to have such a working copy in order to submit changes.
If there is a problem in a portfile, we need to fix the problem in
the portfile, not go back to an earlier version of the portfile. Of
course, we're all volunteers here with other things to do besides
maintain MacPorts, so sometimes it takes awhile to fix problems. If
you know the solution, you can also just locally edit your portfile
(with e.g. "port edit foo" or "cd `port dir foo` && open Portfile")
to fix whatever the problem is. And you can create a ticket in the
Trac system describing the problem and attach a patch so that someone
with commit access can fix it for good. Creating such a patch is
easier when you're using a Subversion working copy ("svn di >
foo.diff"), but if you remember to make a copy of the portfile before
your changes ("sudo cp Portfile Portfile.orig") then it's still easy
enough to get the diff ("diff -u Portfile.orig Portfile > foo.diff").
Be aware that if you "sudo port sync" or "sudo port selfupdate" your
local changes will be overwritten (if you're editing the portfiles in
the tree that MacPorts syncs). The alternative is to set up a
parallel local directory for your modified ports. I believe this
strategy is described in some documentation somewhere, but I haven't
followed it myself so I can't give you the specifics.