Checksum failure with ncbi-tools, then missing getfeat.

[Ryan Schmidt]

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.