Opened 9 years ago

Closed 9 years ago

#27709 closed update (fixed)

revtex: replace with texlive-publishers

Reported by: nickolas.fotopoulos@… Owned by: drkp (Dan Ports)
Priority: Normal Milestone:
Component: ports Version: 1.9.2
Keywords: Cc: skymoo (Adam Mercer)
Port: revtex

Description

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.

Attachments (2)

Portfile (810 bytes) - added by nickolas.fotopoulos@… 9 years ago.
Updated Portfile
test_revtex4-1.tex (220 bytes) - added by nickolas.fotopoulos@… 9 years ago.
Test document

Download all attachments as: .zip

Change History (12)

Changed 9 years ago by nickolas.fotopoulos@…

Attachment: Portfile added

Updated Portfile

Changed 9 years ago by nickolas.fotopoulos@…

Attachment: test_revtex4-1.tex added

Test document

comment:1 Changed 9 years ago by 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

comment:2 Changed 9 years ago by drkp (Dan Ports)

Owner: changed from macports-tickets@… to dports@…
Status: newassigned

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?

comment:3 Changed 9 years ago by 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.

comment:4 Changed 9 years ago by skymoo (Adam Mercer)

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

comment:5 in reply to:  4 ; Changed 9 years ago by 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?

comment:6 in reply to:  3 Changed 9 years ago by 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).

comment:7 in reply to:  5 ; Changed 9 years ago by 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.

comment:8 in reply to:  7 ; Changed 9 years ago by 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.

comment:9 in reply to:  8 Changed 9 years ago by 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.

comment:10 Changed 9 years ago by drkp (Dan Ports)

Resolution: fixed
Status: assignedclosed
Summary: revtex: version bumprevtex: replace with texlive-publishers
Note: See TracTickets for help on using tickets.