Updating unmaintained ports (was: Re: Get date of Portfile)

[Ryan Schmidt]

(Moving discussion to macports-dev from macports-users)


On Apr 17, 2010, at 03:49, Scott Haneda wrote:

> This seems to be the most common of the expressions used:
>    (\d+(?:\.\d+)*)
> Has that been determined the preferred method of making that match?

I believe that's part of the livecheck.regex Anthony decided he prefers. I personally tend to use (\[0-9.\]+) which is less-precise but simpler to type. Either way it would have to be adapted if the software in question uses e.g. letters or dashes or underscores in its version numbers. In the end, it's whatever works for this port's particular situation, and whatever's likely to continue working in the future (based on what you can learn about the types of version numbers and filenames the project has used in the past).

My favorite livecheck which you've probably seen me add to many ports is:

livecheck.type regex
livecheck.regex ${name}-(\[0-9.\]+)\\.tar

This checks the project's homepage (the default livecheck.url is ${homepage}); this works great if they always put a link to download the current version on their homepage. Usually I'll change it to check the master_sites:

livecheck.url [lindex ${master_sites} 0]

This works great if the first URL in the project's master_sites has a directory listing, which for many projects it does. I prefer this to checking the homepage, in case the project forgets to update its homepage when a new version is posted.

Why do I use [lindex ${master_sites} 0] instead of just ${master_sites}? This ensures the livecheck doesn't blow up if the port has multiple master_sites defined. Should you still do this if the port only has a single master_sites entry defined? I say yes, because then the livecheck won't start failing down the road when someone else comes along later and decides to add a second master_sites entry.

Why do I end the livecheck.regex with \\.tar instead of ${extract.suffix}? Because \\.tar covers both .tar.gz and .tar.bz2; I've seen projects switch from one to the other and I wouldn't want to miss a new version because of that. If the project uses .tgz, .zip, or another suffix for its downloads, I might then use ${extract.suffix}.

Note that with my regex I do need to put *something* after the version number match, because if I don't, and the homepage says something like "We released version 1.2.3." then the version matched would be "1.2.3." and not "1.2.3" like we want. With Anthony's more-precise regex, this wouldn't happen.


> Could you walk me through port "mowitz"
> I look at that Portfile and I see the download url is:
>    http://siag.nu/pub/mowitz/
> If I go to that url, it is 404, I then combine it all to test it:
>    http://siag.nu/pub/mowitz/Mowitz-0.3.1
> 
> 404 also.

They appear to be having server problems. I reported the problem to the contact address listed at the bottom of their web page, which is what you should do if you encounter similar problems in the future.


> I do not know the commands to do a test download, so I tried:
>    $sudo port -yv install mowitz

I'll admit I haven't used "-y" before but as Joshua said, just use "sudo port -d fetch mowitz".


> Did I pick a dead port to start on?

Problematic server, anyway; hopefully they'll have that sorted out soon and you can try again.


> If you got from a to k, then you are half there, and must have picked up some tricks along the way.

Don't get me wrong: from a thru k, there were about 300 ports I couldn't / didn't update. For many I was unable to locate the project's current homepage or download URL, so the ports are probably dead. For others, I couldn't get the latest version to build. For others, as you said, I couldn't find a URL on the project's homepage that would tell me the current version from which I could construct a livecheck. For others, I couldn't build their dependencies. And so on. So there's still plenty to do in a thru k but I at least gave it a first pass.


> Would you mind walking me through your process of one port, so I know how to do this in a fast way.

Ok, let me pick one from my to-do list and see what happens.


altermime seems to have been updated (port version: 0.3.6, new version: 0.3.10)

Search for tickets with altermime in the summary... none found. Go to homepage... exists... shows 0.3.10 is indeed the current version. It's over a year old, so maybe the project relocated elsewhere and started doing releases there... Google "altermime"... first hit is the homepage we already have on file. So I guess not, I guess 0.3.10 is all there is.

cd $(port dir altermime)
edit Portfile

("edit" is TextWrangler's command-line helper; if you use BBEdit, the command is "bbedit". Other editors probably have their own commands for this.)

I see the Portfile contains tabs. I want to conform to the Portfile's existing whitespace conventions. My editor defaults to 4 spaces per tab... looks ok. Try 8 spaces per tab... no, looks worse. Go back to 4 spaces per tab. Set editor to not auto-expand tabs.

Edit the version line so it reads 0.3.10.

sudo port -d checksum | edit
Password:

Type password. 
Copy 3 checksum lines to Portfile. Change the spaces in those lines back to tabs matching the portfile's existing whitespace.

sudo port -d install

Fails:

cc -Wall -Werror -g -I. -O2  -c qpe.c
cc1: warnings being treated as errors
qpe.c: In function 'qp_encode':
qpe.c:100: warning: format '%d' expects type 'int', but argument 3 has type 'size_t'

So they've asked to be shown all warnings, and for warnings to be treated as errors, and they have a problem in their code that triggers a warning. I don't care about this warning so want to remove -Werror from the CFLAGS.

cd work/altermime-0.3.10/
edit Makefile

I see they set CFLAGS explicitly, overwriting whatever might be sent in by me via environment variables. I could still send in my own CFLAGS as a make argument, but then I'd be overwriting their CFLAGS, which look specific to the way they build this software so I don't want to do that.

sudo cp -p Makefile{,.orig}
edit Makefile

Change the Makefile to make it append to the existing CFLAGS in the environment variable instead of overwriting them, and remove -Werror and the stuff we already pass in in our CFLAGS, like -O2.

diff -u Makefile{.orig,} > /tmp/p
cd ../..
ls

There's no "files" directory so I'll have to make one.

mkdir files
mv /tmp/p files/patch-Makefile.diff

edit Portfile

Add the line "patchfiles patch-Makefile.diff", and add CFLAGS="${configure.cflags}" to the build.env.

I also see we're not UsingTheRightCompiler because this port has "use_configure no" and doesn't do anything to fix it manually. I'll fix it by adding CC=${configure.cc} to the build.env. If the Makefile had defined a value for CC, I would have instead passed it in build.args to override their value (otherwise their value would have overridden ours).

Note: ${configure.cflags} is in quotes because it is likely there will be a space in this value. ${configure.cc} is not in quotes because it's just the path to the compiler which won't contain a space.

I'll remove the build.target line which isn't doing anything useful here. (The default build.target is "all" and the Makefile does define an "all" target so we'll just use that.)

sudo port -d install

Works! Check that something reasonable got installed.

port contents

Looks ok. Does it run without crashing?

altermime --version
alterMIME v0.3.10 (November-2008) by Paul L Daniels - http://www.pldaniels.com/altermime

Looks ok. Schedule the patchfile for addition.

svn add files/

Make sure all the changes I'm about to commit look reasonable.

svn di

Yup, looks good, commit it.

svn ci -m "altermime: update to 0.3.10 and ensure we're UsingTheRightCompiler"

http://trac.macports.org/changeset/66619

I don't actually need this software so I'll uninstall it to save space.

sudo port uninstall


>> Of course, it's easier to fix if you're a committer and don't have to file a ticket for each one. :/
> 
> You certainly said it.  What if I did a large batch, could I just send you the folders, or is that way out of procedure?

It might be ok, but since I (or whoever) would have to evaluate and commit each one separately, don't send a huge batch because that'll be intimidating. :)

But you know, as you see above, every port has its own quirks. If I were filing a ticket for updating altermime, there might have been some discussion about the best way to handle one or the other of the situations I detailed above. I wouldn't want a ticket to be for more than one port and to have various different ports' discussions intermingled. If you have a handful of ports where you're just fixing their livecheck and nothing else, that's probably ok to file as a single ticket with either a single patchfile or multiple patchfiles attached, but if we're updating port versions, especially of unmaintained ports where considerable time may have passed since the port was last updated and thus considerably more could be expected to go wrong when doing so, let's keep it at one port per ticket.