force install without a dependency

[Ryan Schmidt]

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