Checksum failure with ncbi-tools, then missing getfeat.

[Matt Scilipoti]

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?

On 1/22/08, Ryan Schmidt <ryandesign at macports.org> 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.
>
>