On Jan 21, 2008, at 09:15, Matt Scilipoti wrote:

Thanks for providing a service like macports and going through the effort of creating ports.

I hope you can help me. I'm trying to install ncbi_tools, but I get a checksum error:

% sudo port install ncbi_tools ---> Fetching ncbi_tools ---> Attempting to fetch ncbi.tar.gz from ftp://ftp.ncbi.nlm.nih.gov/toolbox/ncbi_tools/ ---> Verifying checksum(s) for ncbi_tools Error: Checksum (md5) mismatch for ncbi.tar.gz Error: Target org.macports.checksum returned: Unable to verify file checksums Error: Status 1 encountered during processing.

We managed to get the file, md5 it, update the local portfile, and start the install, only to find that getfeat is missing?

% sudo port install ncbi_tools Portfile changed since last build; discarding previous state. ---> Fetching ncbi_tools ---> Verifying checksum(s) for ncbi_tools ---> Extracting ncbi_tools ---> Configuring ncbi_tools ---> Building ncbi_tools ---> Staging ncbi_tools into destroot Error: Target org.macports.destroot returned: xinstall: Cannot stat: /opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_scien ce_ncbi_tools/work/ncbi/bin/getfeat, No such file or directory Error: Status 1 encountered during processing.

Any ideas?

It sounds like the port will need to be updated. Please file a ticket in our issue tracker for this problem, and be sure to enter the port maintainer's email address in the Cc field when you do. "port info ncbi_tools" tells you who that is. http://guide.macports.org/#project.tickets

For future reference... A google search shows that the checksum error has occurred before. This is one of the reasons many libraries have started including version numbers in the file name. This practice also ensures that prior versions of the libraries remain available.

Thanks for attention in this matter.

That's great advice, but it would do more good if sent to the developers of ncbi_tools, not to the MacPorts project, which is merely at the developers' mercy.

On Jan 21, 2008, at 23:25, Matt Scilipoti wrote:

Randy, Thanks for your instruction. I have created ticket #14028 and included michael.thon@yahoo.com in the CC.

More below.

On 1/21/08, Ryan Schmidt wrote: ... snipped ...

...

...

For future reference... A google search shows that the checksum error has occurred before. This is one of the reasons many libraries have started including version numbers in the file name. This practice also ensures that prior versions of the libraries remain available.

Thanks for attention in this matter.

That's great advice, but it would do more good if sent to the developers of ncbi_tools, not to the MacPorts project, which is merely at the developers' mercy.

I would like to assist the port maintainer by directing him to some MacPort specific guidelines, but I was unable to find them on the wiki. I have noticed that python, xfce, and a few others are using a similar convention in MacPorts. Perhaps there are other measures available in MacPorts? I saw that I could install a particular version, but I could not find how to list the available versions.

Available versions? It's only possible to install the version of the software specified in the portfile. If a newer version is available, the portfile should be updated by its maintainer. It is not possible (without a bit of fiddling outside of MacPorts) to install earlier versions. What convention are you observing in python, xfce...? Guidelines for writing ports and for using MacPorts are in the guide at http://guide.macports.org/ . If it needs to be updated with new information, I'm sure the guide authors would appreciate feedback. A ticket can be filed for documentation improvements as well.

On Jan 22, 2008, at 00:37, Matt Scilipoti wrote:

On 1/22/08, Ryan Schmidt wrote:

...

On Jan 21, 2008, at 23:25, Matt Scilipoti wrote:

...

I would like to assist the port maintainer by directing him to some MacPort specific guidelines, but I was unable to find them on the wiki. I have noticed that python, xfce, and a few others are using a similar convention in MacPorts. Perhaps there are other measures available in MacPorts? I saw that I could install a particular version, but I could not find how to list the available versions.

Available versions? It's only possible to install the version of the software specified in the portfile. If a newer version is available, the portfile should be updated by its maintainer. It is not possible (without a bit of fiddling outside of MacPorts) to install earlier versions.

Sorry. I assumed that the @version option in the port command allowed me to specify a version. I wanted to try it, but I couldn't find a port that listed any prior versions. Hence, my question about listing previous versions.

If you have multiple versions of a port installed, you need to use the @version syntax to specify which one you want to activate, deactivate, uninstall, etc.

...

What convention are you observing in python, xfce...?

Including the version number in the file name: python: python21 thru python30, py25-*, py30-* perl5.8 xfce4

Ah, yes. That's only done when there is a need to keep the old version around. For example, rather than updating the apache port to version 2.0 when Apache 2.0 was released, a new port apache2 was created, because the Apache Software Foundation still releases new versions of Apache 1, and modules which work with Apache 1 don't work with Apache 2, so one might conceivably still want to use Apache 1. When Apache 2.2 was released, the apache2 port was updated to version 2.2. However, later someone found a reason to still want to use Apache 2.0, so a new port apache20 was added at that time. I don't use Python, but I understand the various Python versions are not completely compatible with one another either, hence the desire to still be able to install any of those major versions.

...

Guidelines for writing ports and for using MacPorts are in the guide at http://guide.macports.org/ . If it needs to be updated with new information, I'm sure the guide authors would appreciate feedback. A ticket can be filed for documentation improvements as well.

Yes. That's where I looked. While it does state that the MacPort system allows for multiple versions (http://guide.macports.org/#internals.images), it doesn't discuss how to list which versions are available, or how to specify which version you wish to use. I assume you manually update your local portfile: version AND checksums. I guess I have to tell it not to use the listed master_sites as well (either in the portfile or using sources.conf). Or should I bypass all these MacPort layers and adjust the hardlink directly (ie: activate phase)?

The use case is: You have port foo version 1.0 installed and activated. Now the maintainer updates the port to version 2.0. You say "sudo port upgrade foo" and it deactivates foo 1.0 and installs and activates foo 2.0. If you find that foo 2.0 doesn't work properly for your needs, you can "sudo port deactivate foo @2.0" and "sudo port activate foo @1.0" to reactivate the old version, which is still installed on your hard drive, as you can see from the output of "port installed foo". If you decide that 2.0 works for you, then you can "sudo port uninstall foo @1.0" to uninstall it. After that, you will no longer be able to install or activate foo 1.0.

I also don't see any information which would guide a maintainer during a port upgrade.

I haven't read the guide all the way through, but looking at the section headers, I agree, there doesn't appear to be a section specifically for that. There are just sections that explain how to write a portfile. But I agree it would be useful to have a section, maybe even a whole chapter, on how to update a portfile. What if you're updating to a new version of the software? Answer: Update the version and checksums, and if the port revision is nonzero, remove the revision line. If there are any patchfiles, update or remove them as necessary. What if you're changing what files get installed by the port (e.g. adding documentation files) without updating the version? Answer: Increment the port revision What if you're changing the port's dependencies (perhaps to add a forgotten dependency)? Answer: Increment the port revision. What if the update is due to a checksum mismatch and the distname doesn't include the version? Answer: Update the port version, drop the revision line, and make sure the dist_subdir includes the version (see e.g. wxWidgets). What if the update is due to a checksum mismatch because the developer did a stealth upgrade (changed the distfile without updating the software version)? Answer: Increment the port revision, and change the dist_subdir, perhaps to include the version and revision (see e.g. molden). What if you're moving some formerly default behavior to a variant? Answer: Increment the port revision. What if you're *just* adding a variant? Answer: Do not increment the port revision; anyone who wants that variant's behavior would need to reinstall and specify that variant anyway so there's no benefit to forcing everyone to rebuild. What if you're removing a variant? Answer: Increment the port revision so everyone who had the port installed (in particular, everyone who had it installed with that variant) is forced to rebuild without that variant. What if you want to make several unrelated changes to a portfile? Answer: Commit each change separately with a log message that explains not only what you did but also why you did it. What if you want to make whitespace changes to a portfile? Answer: Commit these separately from any functional changes. What if the port has a maintainer? Answer: File a ticket requesting the update and assign it (or Cc it) to the maintainer. If you can attach a patch to implement the update, that will make it that much easier for the maintainer to approve it. If they do not respond within 72 hours, feel free to update the port. What if the port has no maintainer? Answer: Feel free to update the port. What if the port includes openmaintainer in the list of maintainers? Answer: Feel free to make minor changes (such as straightforward version updates) to the port, but it might be nice to let the maintainer(s) know you did this. For major changes or rewrites, file a ticket and assign it to the maintainer, or discuss it with them first via email. What if a maintainer repeatedly fails to respond to tickets or emails? Answer: Remove them from the maintainer list of the port. If this leaves no maintainer or only openmaintainer, set the maintainer to nomaintainer. And so on.

If these sections exist, please direct me to them. Otherwise, I will formulate these questions/suggestions into an enhancement ticket (or tickets).

Thanks again for helping someone who is lost, but trying.

On Jan 22, 2008, at 01:58, Michael Thon wrote:

Regarding the versioning, when the authors of ncbi_tools update their package, the replace the current tarball on their ftp site with the new one and there is no version number in the filename or path [snip]

Have you already contacted the developers to request that they start including version numbers in their distfile names? It would be a good idea for them to do so.

Mike, thank you for maintaining the port. On 1/22/08, Michael Thon <mike.thon@gmail.com> wrote:

Hi Matt - Thanks for letting me know about the outdated port. I'm updating it now and I should be able to submit it to trak later today. When it appears in the repository, i'd appreciate it if you test it and give me some feedback. This port is a 'work in progress'. I haven't tested all the applications it installs, so I don't know if they all work (the ones I use work though).

I'll be happy to test it. Currently, I am only using standalone blastall, but I will look for other testing opportunities. It would be nice if we listed which apps are tested. I expect this would go in http://ncbi_tools.darwinports.com/ and possibly the portfile? It looks like we don't have access to any of the readme files.

Regarding the versioning, when the authors of ncbi_tools update their package, the replace the current tarball on their ftp site with the new one and there is no version number in the filename or path, so the only (easiest?) way to know that its updated is to download it and checksum it. If I was a good port maintainer I would check my ports periodically and submit updates before anyone else, like you, discovers that they're broken :) cheers Mike

I would be happy to help you create an automatic notifier. I have a few tools that notify me when http pages change. Unfortunately, I don't have anything for ftp pages and I don't see a page at ncbi that will be updated when a new ncbi.tar.gz is created. Do you know of an http page? If not, I'm sure I can create something. To tell you the truth, I am having trouble finding any information about this toolkit. NCBI doesn't mention it. The readme(s) within the toolkit are helpful, but limited. I'm here because a google search indicated that this port contained blast and I prefer to use libraries like MacPorts over manual updates. thanks again, matt

<remaining text snipped>

On Jan 22, 2008, at 09:36, Matt Scilipoti wrote:

Thank you for this amazing response. port activate/deactivate answered many questions. I think that I was partially confused during this conversation because I was mixing information about the user role and the maintainer role. ie: How does a user manage available versions vs. how does a maintainer manage them? This response clarified both sides.

One point is now clear, as a user of ports, if I do not already have a previous version of a library installed on my computer, I can not install/activate it using ports -- unless the maintainer creates a separate portfile for each version. I will go the manual route if this condition exists.

If you don't mind, I will create some documentation tickets using (mostly) the information in your response. Should I CC you?

Sure, you can Cc me. I'd be interested to see this properly documented in the Guide too. Just set the Component of the new tickets to "guide" and the Milestone (if it lets you set it) to "Website & Documentation".

On 1/22/08, Ryan Schmidt wrote:

...

On Jan 22, 2008, at 00:37, Matt Scilipoti wrote:

...

On 1/22/08, Ryan Schmidt wrote:

...

On Jan 21, 2008, at 23:25, Matt Scilipoti wrote:

...

I would like to assist the port maintainer by directing him to some MacPort specific guidelines, but I was unable to find them on the wiki. I have noticed that python, xfce, and a few others are using a similar convention in MacPorts. Perhaps there are other measures available in MacPorts? I saw that I could install a particular version, but I could not find how to list the available versions.

Available versions? It's only possible to install the version of the software specified in the portfile. If a newer version is available, the portfile should be updated by its maintainer. It is not possible (without a bit of fiddling outside of MacPorts) to install earlier versions.

Sorry. I assumed that the @version option in the port command allowed me to specify a version. I wanted to try it, but I couldn't find a port that listed any prior versions. Hence, my question about listing previous versions.

If you have multiple versions of a port installed, you need to use the @version syntax to specify which one you want to activate, deactivate, uninstall, etc.

...

...

What convention are you observing in python, xfce...?

Including the version number in the file name: python: python21 thru python30, py25-*, py30-* perl5.8 xfce4

Ah, yes. That's only done when there is a need to keep the old version around. For example, rather than updating the apache port to version 2.0 when Apache 2.0 was released, a new port apache2 was created, because the Apache Software Foundation still releases new versions of Apache 1, and modules which work with Apache 1 don't work with Apache 2, so one might conceivably still want to use Apache 1. When Apache 2.2 was released, the apache2 port was updated to version 2.2. However, later someone found a reason to still want to use Apache 2.0, so a new port apache20 was added at that time.

I don't use Python, but I understand the various Python versions are not completely compatible with one another either, hence the desire to still be able to install any of those major versions.

...

...

Guidelines for writing ports and for using MacPorts are in the guide at http://guide.macports.org/ . If it needs to be updated with new information, I'm sure the guide authors would appreciate feedback. A ticket can be filed for documentation improvements as well.

Yes. That's where I looked. While it does state that the MacPort system allows for multiple versions (http://guide.macports.org/#internals.images), it doesn't discuss how to list which versions are available, or how to specify which version you wish to use. I assume you manually update your local portfile: version AND checksums. I guess I have to tell it not to use the listed master_sites as well (either in the portfile or using sources.conf). Or should I bypass all these MacPort layers and adjust the hardlink directly (ie: activate phase)?

The use case is: You have port foo version 1.0 installed and activated. Now the maintainer updates the port to version 2.0. You say "sudo port upgrade foo" and it deactivates foo 1.0 and installs and activates foo 2.0. If you find that foo 2.0 doesn't work properly for your needs, you can "sudo port deactivate foo @2.0" and "sudo port activate foo @1.0" to reactivate the old version, which is still installed on your hard drive, as you can see from the output of "port installed foo". If you decide that 2.0 works for you, then you can "sudo port uninstall foo @1.0" to uninstall it. After that, you will no longer be able to install or activate foo 1.0.

...

I also don't see any information which would guide a maintainer during a port upgrade.

I haven't read the guide all the way through, but looking at the section headers, I agree, there doesn't appear to be a section specifically for that. There are just sections that explain how to write a portfile. But I agree it would be useful to have a section, maybe even a whole chapter, on how to update a portfile.

What if you're updating to a new version of the software? Answer: Update the version and checksums, and if the port revision is nonzero, remove the revision line. If there are any patchfiles, update or remove them as necessary.

What if you're changing what files get installed by the port (e.g. adding documentation files) without updating the version? Answer: Increment the port revision

What if you're changing the port's dependencies (perhaps to add a forgotten dependency)? Answer: Increment the port revision.

What if the update is due to a checksum mismatch and the distname doesn't include the version? Answer: Update the port version, drop the revision line, and make sure the dist_subdir includes the version (see e.g. wxWidgets).

What if the update is due to a checksum mismatch because the developer did a stealth upgrade (changed the distfile without updating the software version)? Answer: Increment the port revision, and change the dist_subdir, perhaps to include the version and revision (see e.g. molden).

What if you're moving some formerly default behavior to a variant? Answer: Increment the port revision.

What if you're *just* adding a variant? Answer: Do not increment the port revision; anyone who wants that variant's behavior would need to reinstall and specify that variant anyway so there's no benefit to forcing everyone to rebuild.

What if you're removing a variant? Answer: Increment the port revision so everyone who had the port installed (in particular, everyone who had it installed with that variant) is forced to rebuild without that variant.

What if you want to make several unrelated changes to a portfile? Answer: Commit each change separately with a log message that explains not only what you did but also why you did it.

What if you want to make whitespace changes to a portfile? Answer: Commit these separately from any functional changes.

What if the port has a maintainer? Answer: File a ticket requesting the update and assign it (or Cc it) to the maintainer. If you can attach a patch to implement the update, that will make it that much easier for the maintainer to approve it. If they do not respond within 72 hours, feel free to update the port.

What if the port has no maintainer? Answer: Feel free to update the port.

What if the port includes openmaintainer in the list of maintainers? Answer: Feel free to make minor changes (such as straightforward version updates) to the port, but it might be nice to let the maintainer(s) know you did this. For major changes or rewrites, file a ticket and assign it to the maintainer, or discuss it with them first via email.

What if a maintainer repeatedly fails to respond to tickets or emails? Answer: Remove them from the maintainer list of the port. If this leaves no maintainer or only openmaintainer, set the maintainer to nomaintainer.

And so on.

...

If these sections exist, please direct me to them. Otherwise, I will formulate these questions/suggestions into an enhancement ticket (or tickets).

Thanks again for helping someone who is lost, but trying.

On Jan 22, 2008, at 5:28 PM, Matt Scilipoti wrote:

It would be nice if we listed which apps are tested. I expect this would go in http://ncbi_tools.darwinports.com/ and possibly the portfile? It looks like we don't have access to any of the readme files. I have considered making a general info web page about some of the science ports in MacPorts, but I haven't had time to do so. There are man pages for the applications in this package, but, like most command line apps, unless you know the name of the executable, you don't know which man page to read. There is some additional documentation in text files that currently are not installed. I'll try to fix that with the next update of the port.

some of the applications in this package require a few env variables to be set, and as far as I know, the macports system cannot do that. I don't know what's the best way to deal with that - perhaps an informational message thats printed at the end of the install?