After a long 5 years, fortune-mod is once again actively maintained. From http://www.redellipse.net/code/fortune/: There are quite a few differences between this version of fortune, and the one which is currently available for most distributions. These changes include: * Some internationalisation support * UTF-8 support * Zillions of extra fortunes that have been suggested to the Debian maintainers over the last 5 years * Number of spelling fixes. * Fixes to REGEXPs searches * Changes in percentage allocations * A few bug fixes * A Y2K compliant version number * Some other stuff I've probably forgotten about ;-) I had a problem with the '-m' option, which is supposed to search for fortunes matching an arbitrary regexp. It would segfault sometimes without printing anything, and other times it would print out a few fortunes and then segfault. I found the offending code in fortune.c in matches_in_list() on line 1581: if (fp->utf8_charset) free (output); I'm not exactly sure how the whole function works, but when i removed this code the '-m' option worked fine. Emailing the maintainer about this. Oh yeah, and portage thinks that 1.99.1 is older than 9708. Is there a way to specify version order in the ebuild?
Created attachment 26952 [details] fortune-mod-1.99.1.ebuild
Hrrrmn... unfortunately, there is no way that I know of to "force" an ebuild to install over another. I think we'll definitely need to investigate this one a bit more before we can add it.
No problem. First we add the new version to portage, then mask the old version in profiles/package.mask. It's pretty straight forward.
>No problem. First we add the new version to portage, then mask the old version in profiles/package.mask. It's pretty straight forward. I know we can do that, but do you guys think specifying version order would be a good idea for portage? It would probably only be a good idea if there are other packages out there that do something funky like this.
That would be useful in these few fringe cases where it happens, butit would make for a pretty hefty maintenance nightmare to keep up with version orders, unless it was completely optional. SpanKY, what's the plan on this one?
9708 becomes 1.0.9708 and we delete 9708 then we add 1.99.1 as unstable everyone in stable goes to 1.0.9708 (it's a small program so i dont care about the recompile hassle) while everyone in unstable goes to 1.99.1
This has been done in CVS
