(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.
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
