On May 12, 2008, at 5:00 PM, Jacob Schwartz wrote:
On Mon, May 12, 2008 at 4:56 PM, Ryan Schmidt wrote:
No. MacPorts is designed to accept only its own ports as satisfying
dependencies, not any other versions of that software you may
already have
installed.
Can I rephrase my question then? What if the port maintainer included
a bogus dependency -- in this case, the Haskell-mode for emacs *in no
way* requires the port "ghc". Absolutely does not require it. The
Haskell-mode can be very useful to people who never intend to run
"ghc". What now? We contact the port maintainer and ask them to fix
the problem and then wait for them to update the macports database
before we install?
Yes. If there's a wrong dependency in a port (or any other error in a
port), we want the error reported to the maintainer and/or a bug
created in the issue tracker so that it can be fixed.
I'll go ahead and contact the maintainer and ask them to do that ...
but it would be nice, as a user, to be able to tell "port" that I know
that some information in the portfile is wrong and I'd like to replace
it with a new value.
You can edit the portfile locally if you like. You can type "port
edit foo" to edit foo's portfile if you have your EDITOR environment
variable set up correctly. Or you can type things like "port file
foo" or even "open `port dir foo`" to see where foo's portfile is on
your hard drive and then drag it to your favorite editor. Changes you
make to the portfile will go away the next time you "port sync" or
"port selfupdate".
For example, here's a similar issue that I ran into, involving the
version in the portfile:
The portfile for "yudit" from macports refers to a sunsite location
where the source files can be found and the portfile specifies a
specific version (2.7.6). The ftp-site put up a new version (2.9.0)
of the source files and *removed* the old version. I was stuck! I
couldn't install the port because macports insisted on a particular
version, but the file for that version was no longer available.
The port needs to be updated in that case. Please file a ticket if
one does not already exist.
Most developers keep at least some older distfiles around for a time.
However 2.7.6 may be much older than 2.9.0. And the yudit port has no
maintainer, so nobody's been keeping the port up to date. If you are
interested in yudit, you could volunteer to be its maintainer and
submit a diff to update it to the current version. Then this problem
wouldn't happen to other users.
Not too long ago we discussed a mechanism by which Mac OS Forge will
mirror all ports' distfiles, which will eliminate the problem where
an older distfile has been removed from the developer's web site.
However this has not yet been implemented.
However ... The "port" command has an option to search for whether new
versions exist ("livecheck" I think?), and it worked very well: "port"
told me that it found the new version on the website:
# sudo port livecheck yudit
yudit seems to have been updated (port version: 2.7.6, new
version: 2.9.0)
My question: Is there any way that "port", having found the new
version, can install that version? I found no mention of this in the
documentation. So not only could I not install the old version, I
couldn't install the new version!
"port livecheck" is just meant for the port maintainer to use on a
regular basis to see if he needs to update the port. If a maintainer
does not do so, or if the port has no maintainer, a user can also use
livecheck, and file a ticket if a the port needs to be updated to a
newer version.
What do I do in that situation? Again, I have to contact the port's
maintainer and tell them to update the macports database to the new
version? In this case, the port has no maintainer, so who do I
contact?
File a ticket. You can put my email address in the Cc field if you
like and I'll try to take a look at it. Or someone else who looks at
the new tickets can take it.
If "port" can know about a new version, why can't it install that
version if I ask it to? I figured that I could probably create my own
portfile in which everything is the same except that I change the
version number; then I run my own ports server and list it among the
servers in the config file for "port" ... but this seemed like too
much work. If it's something I could do myself by setting up a local
port server, why can't I have "port" do it on the command line and
save me the effort?
Many version updates are as simple as just changing the version
number and the checksums. But not all are. For example, when cairo
was updated from 1.4.x to 1.6.x, it was necessary to add a new
dependency on libpixman. In other ports, new versions may necessitate
adding new patches to fix Mac OS X build issues, since not all
developers test with Mac OS X. Or, old patches may have become
obsolete and need removing.
This is why we have port maintainers -- to maintain the ports and
provide some rudimentary assurance that they work. Ports with no
maintainer are available for adoption by anyone interested in that port.
Please file tickets as you find things that need fixing. For ports
with a maintainer, include the maintainer's email address in the
ticket's Cc line. If the maintainer does not respond within 72 hours,
or if the port has no maintainer or is marked openmaintainer, any
committer can commit the change. You can send ticket numbers to this
list to request that someone look at them, if nobody has done so in
awhile.
http://guide.macports.org/#project
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-users
