revtex: replace with texlive-publishers

[nickolas.fotopoulos@…]

The revtex package is out of date and has no maintainer. I have updated the Portfile from revtex4 to revtex4-1 and provide a new distfiles tarball. (Macports appears to need a .tar.gz with a particular directory structure and the actual payload needed is provided in nested zip files from the revtex authors.) It works in my local testing.

I'd appreciate it if someone else could test (compile attached test document with "pdflatex test_revtex4-1") and critique my first attempt. If there are no problems, please commit.

[nickolas.fotopoulos@…]

Updated Portfile

[nickolas.fotopoulos@…]

Test document

[nickolas.fotopoulos@…]

The tarball is larger than the attachment filesize limit, so I've uploaded it temporarily to a webserver:

​http://www.its.caltech.edu/~foton/revtex4-1.tar.gz

[drkp (Dan Ports)]

Thanks for the update!

Were you aware that revtex is also available in the texlive-publishers package? I think it's the same version (it's 4.1, not sure of the patch level). Is there a benefit to keeping revtex around as a separate port, or would it be better to deprecate the port and replace it with texlive-publishers?

[nickolas.fotopoulos@…]

texlive-publishers seems like a very nice alternative indeed. Would there be any way to make the description more verbose such that "port search revtex" would also return texlive-publishers? Version number is also important. Would it be too complicated to make it a meta-package that pulls in whatever explicit sub-packages exist, then provide the rest itself?

I'm exploring the solution space and discoverability is a big deal in my mind.

[skymoo (Adam Mercer)]

An option could be to make the revtex port a stub and mark it replaced_by texlive_publishers?

[nickolas.fotopoulos@…]

Replying to ram@…:

An option could be to make the revtex port a stub and mark it replaced_by texlive_publishers?

That would satisfy the discoverability criterion, but it does add extra maintenance burden should dports want to keep the version number up to date, which I'd encourage him to do. Also, is it common to leave obsolete ports lying around forever merely for advertising a subset of another port?

[drkp (Dan Ports)]

Replying to nickolas.fotopoulos@…:

texlive-publishers seems like a very nice alternative indeed. Would there be any way to make the description more verbose such that "port search revtex" would also return texlive-publishers? Version number is also important.

Yes, I agree that discoverability is important and the current state of things isn't great -- how is one to know that revtex is in texlive-publishers or that lineno is in texlive-humanities or that the rest of the known universe is hiding in texlive-latex-extra. There is ​http://trac.macports.org/wiki/TeXLivePackages, but that's not exactly discoverable itself!

Putting the list of package names into the long_description sounds like a good idea. Unfortunately I don't have version number information for every package. (Well, other than that revtex and revtex4 are separate packages.)

Would it be too complicated to make it a meta-package that pulls in whatever explicit sub-packages exist, then provide the rest itself?

We've done this when it's useful to do so for some reason, e.g. with pgf. In general, I'd rather not because then we'd have to keep the individual packages up to date, which was what I was hoping to avoid!

More generally, we have a bunch of ports that install individual tex packages which are also in texlive and it's not clear what we should do with them. Most of them date back to the teTeX days and some (but not all) are unmaintained and/or outdated. Perhaps it's best to mark them as replaced_by the appropriate texlive package, so we wouldn't have to worry about explicitly keeping it up to date (or making sure it actually works correctly with texlive, which I'm not even sure of in some cases...).

The obvious disadvantages to doing this are that the packages might be harder to find, and you'd lose the ability to install them individually. With separate ports we could also apply updates to get a more current version than the latest texlive, but in practice the opposite seems more likely. A bigger possible problem is that we'd lose the ability to use these ports with pTeX, a teTeX-based distribution (or, I guess, teTeX itself, but it's so long dead that I'm not going to expend any effort worrying about maintaining compatibility with it).

[drkp (Dan Ports)]

Replying to nickolas.fotopoulos@…:

Replying to ram@…:

An option could be to make the revtex port a stub and mark it replaced_by texlive_publishers?

That would satisfy the discoverability criterion, but it does add extra maintenance burden should dports want to keep the version number up to date, which I'd encourage him to do. Also, is it common to leave obsolete ports lying around forever merely for advertising a subset of another port?

When we mark one port as replaced_by another, we need to keep the portfile stub around -- usually for a year or so -- so that users who have the old port installed will see that it has been replaced rather than simply gone missing.

In such a case we wouldn't keep the version number up to date.

[nickolas.fotopoulos@…]

Replying to dports@…:

Replying to nickolas.fotopoulos@…:

Replying to ram@…:

An option could be to make the revtex port a stub and mark it replaced_by texlive_publishers?

That would satisfy the discoverability criterion, but it does add extra maintenance burden should dports want to keep the version number up to date, which I'd encourage him to do. Also, is it common to leave obsolete ports lying around forever merely for advertising a subset of another port?

When we mark one port as replaced_by another, we need to keep the portfile stub around -- usually for a year or so -- so that users who have the old port installed will see that it has been replaced rather than simply gone missing.

In such a case we wouldn't keep the version number up to date.

I think this is the best solution, even without the version information. I'd also advocate keeping the stub as long as possible, purely for discoverability. dports, are you willing to do this or shall I figure out the replaced_by business? (Also, even in the revtex stub, I'd bump to 4-1 nominal version number anyway, to at least advertise the correct current version in texlive-publishers.)

Many thanks.

[drkp (Dan Ports)]

Replying to nickolas.fotopoulos@…:

I think this is the best solution, even without the version information. I'd also advocate keeping the stub as long as possible, purely for discoverability. dports, are you willing to do this or shall I figure out the replaced_by business? (Also, even in the revtex stub, I'd bump to 4-1 nominal version number anyway, to at least advertise the correct current version in texlive-publishers.)

I'll take care of it.

[drkp (Dan Ports)]

r74743