Checksum failure with ncbi-tools, then missing getfeat.

[Ryan Schmidt]

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.